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ABSTRACT 

Thi ( report comprises a detailed evaluation of two 
mini compute r*based school information management systems for use at 
the senior high school level: (1) Prompt Automated Scheduling System 
(PASS) by Mid-American Corporation and locally developed software, 
which runs on an IP^ minicomputer, and (2) Student Administration 
System (SAS) by SIERRA Software Systems, Inc., which runs on the 
Digital Equipment VAX family of computers. These two systems were 
evaluated against six major factors, each defined by a detailed and 
comprehensive set of criteria: product scope ^nd function, ease of 
use, technical cottsiderations, support add services, product 
qualifications, and vendor. All key syster capabilities were tested 
as they related to database creation and maintenance, preschednling, 
scheduling, transition to operational status (and semester turnover), 
attendance recording and reporting, progress recording and reporting, 
report generation, and utility functions. Each product evaluation 
describes the testing environment and conditions, liits evaluation 
results and observations, and summarizes the strengths and weaknesses 
of the system. Evaluation data are then summarized and compared ^irst 
from the senior and then from the junior high school perspective. 
Results indicate that considerable development work Is required for 
both systems to realize ccMtplete school information management 
systems, and that these minicomputer-based systems are not suitable 
tor ase by individual schools. Six appendixes are included: the 
g»meral questionnaire from which the criteria were derived, the 
ifiterview guide and detailed checklist, the detailed scoring 
comparison form. Mid-American PASS screen and program functions, IBM 
4341 to VAS ll/t25 data transfer, and recent system develotxnents. 
(TE) 
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1 .0 INT RODUCTION 



Until fairly recently, those major school administration functions which 
were addressed by computers, were central, mainframe ~ based 
applications. Over time, minicomputers and microcomputers have increased 
in power and become more affordable. There are now several comprehensive 
administrative systems available for such computers. School 
administrators are becoming increasingly interested ia the local 
application of computer technology to school information management. 
While microcomputers have very low price to performance ratios they are 
almost always limited to a single user and a single task at any one 
time. Minicomputer systems are considerably more powerful in terms of 
the processing speed, nup.ber of users (typically eight) and 
sophistication and power of the operating system and database management 
system. 

Among the computer based applications which exist for school 
administrators today are School Information Management Systems (SIMS) 
with a particular focus on student related information. These systems 
may be microcomputer or minicomputer based and, typically, incorporate 
four major modules which address school records, student scheduling, 
student attendance and marks or progress reporting. Usually, there is a 
high degree of integration between the modules which meanc, for example, 
that duplicate data bases are not required. In most cases, the cost of 
these software systems belies their complexity. Four thousand dollars 
buys multi-megabytes of software opportunity. In all cases, it is safe 
to assume that the cost of the software system itself will be the least 
impacting factor in any decision to app]y it. 

The purpose of the work which is reported on here was to evaluate the 
comparative suitability of two minicomputer based SIMS for use at the 
senior high school level. One of these SIMS focussed ot the evaluation 
of commercially available software which runs on the DEC VAX family of 
computers. The second featured a combination of purchased and locally 
developed software which runs on an IBM minicomputer. This project was 
part of a wider investigation of SIMS alternatives for high school use. 
Specifically, Edmonton Public Schools and Alberta Education jointly 
funded the Investigation of microcomputer based approaches to school 
information management as well. This latter initiative is the focus of a 
separate report. All investigations (of boch mini and microcomputer 
based systems) were performed according to a thorough and objective 
evaluation process which was developed specifically for the purpose. The 
approach to evaluation is described in detail in a report entitled 
Selection Criteria for Integrated School Information Management Systems 
(available from Alberta Education). 
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In view of the extremely high level of interest in this area, the scope 
of the project was widened to include the junior high school 
perspective. The systems evaluated were: 

o Prompt Automated Scheduling System (PASS) by Mid-American C' rp.and 

locally developed software 
o Student Administration System (SAS) by SIERRA Software: Systems Inc. 

The PASS alternative was comolemcnted by a significant amount of locally 
developed software (e.g. an attendance tracking and reporting system). 

The evaluation of the PASS centred system began in 1983. Development of 
integrated attendance and database updating software was completed in 
January 1984. The system is now in live use at Jasper Place Composite 
High School. The SAS evaluation started in October 1984 and was 
completed in February 1985. 

The PASS centred system, was tested on an IBM Series 1 minicomputer; the 
SAS package was tested on a Digital Equipment VAX i 1/725 minicomputer. 
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2.0 APPROACH TO EVALUATION 



2 • 1 Evaluacion Criteria 

The two systems under investigation were evaluated against six major 
factors. These major evaluation factors were: 

o Product Scope aad Function <,what does it do and how well does it do it) 
o Ease of Use (User friendliness) 

o Technical Considerations (system design, structure, operation, etc.) 

o Support and Services (after sales service) 

o Product Qualifications (product credibility, history, etc.) 

o Vendor (who stands behind the product) 

Each of the six major evaluation factors was defined by a detailed and 
comprehensive set of criteria. Information gained from consultations 
with schools was paramount in the development of the criteria. The 
criteria were developed through a six step process as outlined below: 



Step 1 A General Questionnaire (see Appendix 1), Interview Guide and 
Detailed Checklist (see Appendix 2) were developed for the 
gathering of Information from the schools. These documents were 
developed using information gained through prior, extensive 
contact with schools in general, through the experiences of 
Information Services staff, and with a working knowledge of the 
characteristics of currently available systems. The general 
questionnaire was designed to determine which features and 
characteristics a SIMS should include and, in many cases, their 
relative importance. Where measures of the relative importance 
of a criterion or characteristic were required, the 
questionnaire featured a simple four point "must, "important", 
"optional" and "not required" scale for respondents to check. 

^^t^ep 2 Eight^ien district schools were identified as a respresenlat ive 
sar?ple through which detailed school information management 
needs and requirements were confirmed. These schools were 
carefully chosen to reflect many of the key variables such as 
schoo] level, size, programs, organization and operational 
style. 

-"^^^P 3 The General Questionnaire was sent to the 18 identified schools 
together with a statement of its purpose and instructions for 
its completion. Participating schools were xequested to give 
careful consideration to their responses to the questionnaire 
and to prepare for a follow-up interview. The questionnaire 
alt>o allowed participants to respond to the needs and 
requirements not specifically identified in the survey. 
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S tep 4 



Step 5 



Step 6 



After allowing ample time for the completion of the 
questionnaire, follow-^up interviews were conducted at each 
school using the I.iterview Guide ar d Detailed Checklist referred 
to previously. The purpose of this step was to clarify and 
confirm responses relative to the questionnaire. A key reason 
for the two stage information gathering process (questionnaire 
followed by the interview) was to allow the schools to first 
respond without external influence of any kind. 

Information gathered through the administration of the 
f^.uestionnaire and subsequent interviews was compiled and 
analyzed and used to determine the relative importance uf 
selection criteria items. Particular attention was paid to the 
comments of participating schools since this sometimes led to 
the inclusion of additional criteria items .tfhich might otherwise 
have been missed. 

Simple qualitative and quantitative analysis of the 
questionnaire, its findings, and the results of the interviews 
led to the definition of the detailed criteria as we'tl as to the 
determination of weighting factors. The detailed evaluation (or 
selection) crlterid in tabular form and a description of the 
column entries are shown in the following pages. 
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EVALUATION 
FACTOR 


CKlTtKlA ITEMS 


WEIGHT 
(W) 


SCORE 
(S) 


WEICHTEO SCORE 
(U X S) 


MAX vr sayv: 

(W X S ) 


Vr SCORE/MAX VT SCORE 


PRODUCT 
SOOR 4 
PUHCnON 


SCHOOL RECORDS 
Pre-Reglstration/Enrollment 
Create student record 


15 












- school student KD, 

- last nafhL 

- middle nam 

- first name 

- birthdate 

- current grade 

- sex 

- feeder school 
" home address 














registration confirmation notice 


3 












Feeder school confirmation notice 


2 












TOTAL Pre-Segistratloa'^ViroIlnent 


20 












Detailed Data Items 














Student Information 


25 












- school student I.D. 

- D^itrict stucient I.D. 

- Alberta Education student I.D. 

- last name 

- middle name 

- fik'at name 

- birthdate 

- current grade 

- sex 

- feeder school 

- lionc address 

- telephone number 


* 











EVALUATION 
FACTOR 


CRITERIA ITEKS 


WEIGHT 
(W) 


SCORE 
(S) 


WEICJITED SCORE 
(W X S) 


MAX WT SCORE 

(W X S ) 
max' 


WT SCCRE/MAX WT SCORE 




- emerj^ency contact 

- nsT£ 

- telephone 

- entry Information 

- entry date 

- registration code 

- withdrawal code 

- previous schools (2) 

- honerooB instruction 

- counsellor 

- parent /guardian information (up to 4) 

- name 
address 

- telephone (ic^^oe and business) 

- relationsldp 

- occupation 

- locker information 

" number 

- combination 

- student indebteuness 

- religious denominatii v 
' program type 

- number o^ credits earned 

- this school 

- other schools 

- academic history 

" travel information 

- method 

- distance 

bus pass information 

- parking information 

- driver's licence 

- licence plate 

- parking space 

- medica]! information 

- disabilities/behaviours 

- medications 

- allergies 
. 













15 
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EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


SCORE 
(S) 


WEiaiTED SCORE 
(W X S) 


hAX WT SCORE 

(W X S ) 
max' 


WT scoRh/MAx urr scoRi": 




- date of last medical 

- physician informtition 

- health care number 
- departure Information 

- date 

- reason 

' ndnivjii of 6 user defined fields 














Instructor Inforoation 


5 












- instructor code 

- name 

- address 

- telephone 

- social insurance nuuber 

- language of instruction 

- certificate number 

- courses taught 

- mininun of 6 user defined fields 
Courbe information 


J5 












- course code (5 character alpha-n«imeric) 

- description 

- pre-and co-requisites (mininia of 4) 

- oust h&ndle"and*7**or "situation 

- course type 

- language of instruction 

- course accreditation 

- credit value (2 digits) 

- pass/fail mark 

- grade 

TOTAL Detailed Dtta IteM 



























EVALUATION 
FACTOR 



CD 
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CRITERIA ITEMS 



Reports/Inquiries 

All reports and inquiries should be avail- 
able for all or a specified range of 
records^ in various sort orders. 

- class lists 

- hoioerooai lists 

- student name labels 

- student address labels 

- parent address labels 

- student I.D. cards 

- student data (alphabetical or numerical 
order) 

" parent data (alphabetical or numerical 
order) 

- instructor data (alphabetical or numer- 
ical order) 

~ course data 

- student phone list 

- student name list 

- student grade list 
~ feeder school list 

- locker information list 

- student population by instruction type 

- fee sh .its 

The system should allow production of 
user-defined reports/ inquiries using 
available data. 

IDtAL Beports/lnquiries 

TOrtAL SCmOL EROQKDS 



WEiGirr 
(w) 



25 



23 



90 



SCORE 
(S) 



WEIGHTED SCORE 
(W X S) 



MAX WT SCORE 



WT SCORF/MAX WT Sa>RE 



19 



20 



EVALUATION 
FACTOR 


CRITERIA ITEMS 




SQSDULIIC 




Detailed Data Items 




- Course code 

- Course section 




Manual scheduling (Arena Scheduling) 




Pre-scheciuling 




Course Requests 




manual entry 
automated entry 




- allow student to specify manda^^ory/ 
compulsory courses , 

- preferred courses, preferred 
alternatives, etc. 

- alJow student to specify preferred 
section, semester, or instructor 




Edit and validation of course requests 




- -hecking of pre- and co-requisites in 
the current students' requests as well 
as history files 

" capability to override pre- and co- 
requisites 

- capability to conplete p^e-requisite 
checking for students from other 
District schools. 

Pre-scheduling reports 




- potential conflict matrix — for all 
or a specified raagc of courses. 
Additional selection criteria may be 



ERIC 



wEicirr 
(w) 



SCORE 
(S) 



WEIGHTED SCORE 
(W X S) 



*1AX WT SCORE 

(W X S ) 
max' 



Wr SCOPE/MAX WT SCOR.P 



7 



2 
9 



21 



EVALUATION 
FACTOR 



CRITERIA 1TE>1S 



2'^ 
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based ori the number of requests or the 
number of sections. 

- course tally 

- students with no requests 

- student course request list 

- min/nax request list 

- ttin/nax credit list 

- verification tickets 

- arena scheduling labels 

- students missing compulsory courses 

- students requesting specific course or 
group of courses 



Master schedule builder 

Capability to build a master schedule 

manually 

automatically 
Capability of handling a variety of 
Scheduling units 

- full year 

- semester 

- trimester 

- quartermester 

- 6 week unit 

- any combination of the above 

User defined timetable rotation/tumble 
Fleidble number of periods per day 
Capability to specify exclusive male or 
female sections 

Capability to maintain current and future 
year/semester master schedules 



WEIGHT 
(W) 



SCORE 
(S) 



WEIGHTED SCOPJi 
(W X S) 



MAX Wr SCORE 



WT SCORF/MAX WT SCORE 



6^ 
9 



10 




EVAIDATKW 
FACTDR 



CRITEKIA IThHS 



Scheduling Process 

User defined scheduling sequcncii 

- low grebes first 

- high gravies first 

- A to Z 
~ Z to A 

Unsc!cduling of no-shovs/wlthdrawals 

Scheduling of individual student or small 

groups of students 

Capability to reset all students or 

partially scheduled students 

Capab. lity to lock sc'ieduling assigniiKnt^ 

for all students or a group of students 

Restart capability 

Course weighting/ semester balancing 

(ensure even course load for students) 

Blocking of courses 

Section balancing 

Class balancing (aales-females) 

Capability keep sc^^duling open after 

school start uhlle starting to use the 

attendance oiodule 

Scheduling Reports/ > nquiries 

" student tinetables — grid and list 
format 

- instructor timetables — grid avid list 
format 

- room timetables — grid and list formut 

- master schedule 

student scheduling conflicts 

- students partially scheduled 

- unassigned time 



WEiGirr 
(w) 



SOKE 
(S) 



WEICirrED SCORE 
(W X s) 



K^x WT sooRf: 

max 



6 



6 



8 



8 




CO 




8 




7 




8 








9 





10 
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EVALUATION 
FACTOR 


CRITERIA ITE>1S 


WEIGHT 
(W) 


SCORE 
(S) 


WKICHTED SCORE 
(U X S) 


MAX Vr SCORE 


WT SCORE/MAX WT SCORE 




Junior High Scheduling Requirenencs 














Hoinerooa grouping for core subjects 


9 












Capability of scheduling any course in 
any conbination and number of tine 
periods 


10 












TOTA' SOKDULmC 


200 












SnJDENr KiTQSMJXX 














Entry ^f Attendance Data 














manual entiy 


5 












automated entry 


9 












Multiple user-defined absence types 


8 












Capability to record attendance data at 
various intervals 


10 












- dally 

- twice per day 

- period by period 

- subject by subject 














Attendance history 


8 












- at least ten days detail 

- cumulative totals 














Attendance reports/inquiries 


10 










1 


- student by class 

- student by subject 

- student by period 













EVALUATION 
FACTOR 
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CRITERIA ITEMS 



- homeroom attendance 

- daily summary 

- weekly summary 

- nunthly sumnary 

- iTxjltiple absence 

- capability to produce unexcused 
absence report f^r the current day 
t/ithin 30 minutes 

- the system should allow user defined 
reports/inquiries using available data 

TOTAL AmEMQANOe 



STUDENT MARKS 

Entry of marks data 

manual 
automated 

Narks data 

- minimum of 4 terra marks plus final mark 

- letter or percentage grades 

Student Exams 

Exam timetable builder 

- automated 

- manual 

Exam Report /Inquiries 

- potentla] exam conflict matrix 

- exam sctiedules 



WEIGHT 
(W) 



50 



10 



SCORE 
(S) 



WEIGHTED SCORE 
(W X S) 



MAX WT SCORE 



wr scoRE/iiAx wr score 
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EVALUATION 
r 1 wK 


CHITERL\ ITEMS 


WEIGHT 


SCORE 


WEIGHTED SCORE 
(W X S) 


MAX Wr SCORE 
(W X S ) 


wr sa)RE/MAx wr score 




Reports/Inquiries 


10 












proof list 
report cards 

- marks data 

- final nark, calculated according to 

- user-defined form 

- attendance data 

- class averages 

- honour lists 

_ nof'pnf'ial f^i'lluro 1'icfc 

- graduation list 














TOTAL SrUDEKT MARKS 














irriLITY FUNCTIONS 














Backup/Restore 


12 












Secur i t y / Con t ro 1 s 


8 












TOTAL irriLm FUNcnows 


20 






























400 ! 

1 






















EASE OF 


- flexibility 


60 










USE 


- raDdular, table driven 
- menu driven 














GRAND TOTAL » EASE OP DSR 




60 
















I 

1 




C_.. . 
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EVALUATION 
FACTOR 



TEOtaCAL 

OONSIDERATIONS 



SUPPORT 4 
SERVICES 



CRITERIA ITEMS 



hardware 

system software v^nvi^onroent 

- operating system 

- utilities 

" database management /system 
intemaln/f iles 

- networking capabilities 

- user hooks 

- modularity of the system 



GRAND TOTAL, TECHNICAL CONSIDERATIONS 

" local versus where/how far 

- package support and services 
- software support, custom 

modifications 

- documentation 

- user guide, application system, 
procedural, operations guide, 
file layouts 

- training 

- applications system, operational 
(DP), availability schedule, fomwt 
location, prerequisites 

- implementation 

- training 

- initialization (conversion, file set- 
up, output forms) 

- implementation plan 



GRAND TOTAL, SUPPORT & SERVICES 



WEIGHT 
(W) 



80 



80 



70 



SCORE 
(S) 



70 



WEIGHTED SCORE 
(W X S) 



MAX V/r SCORE 



wr sa)RE/MAX v/r score 



1 



EVALUATION 
FACTOR 



CRITERIA ITEMS 



PRODUCT 
QUALIFICATIONS 



VENDOR 




WEIGHT 
(W) 



80 



package background 
reliability 

current development status 
nuober of installations 
product development plans 
release concept, portability, 
verticality 



GRAND TOTAL, PRODUCT QUALIFICATIONS 



- Corporate information 

- background and history 

- financial performance 

- employee base 

- Market volatility and vendor stability 

- References 

- Contractual Terms 

- maintenance 

- warranty 

- ownership rights 

- discount structure/price limit 



80 



70 



GRAND TOTAL » VENDOR 



70 



SCORE 
(S) 



1 



WEIGHTED SCORE 
(W X S) 



MAX V/r SCORE 



WT SCORE/MAX WT SCORE 



i 1 
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The extreme left hand column of the tables shows the major evaluation 
factors. The column immer'iately to the right of this displays the 
criteria items. Major criteria items are underlined. Below each major 
criteria item is a list of detailed criteria. The detailed criteria are 
of two types - those against which the systems under evaluation will be 
scored and those which are to provide context for the scoring process.. 
Criteria provided for context purposes are identified by a preceeding 
hyphen. Those criteria against which systems were scored can be 
identified by the presence of an entry in the column marked WEIGHT 
(weighting factor). 
The column entries for the Criteria Tables are defined as follows. 



Evaluation Factor 



Criteria Item 



Weight 



identifies a key area of evaluation and the 
beginning of a detailed criteria list for that 
particular f acLoi . 

identifies a feature, process or attribute 
a^^sociated with the factor. The Criteria item 
column also contains supplementary entries 
intended to provide an " ^ator with a more 
complete perspective on a particular criteria 
item being evaluated. Supplementary entries, 
which are identified by a preceeding hyphen, do 
not have a weight assigned to uhem. 

is a measure of the relative importance of a 
criteria item to the user. Summing of 
weighting factors (or weights) gives a broad 
perspective of the relative importance of major 
areas or modules within the context of the 
entire evaluation. Weights are assignable at 
the discretion of the user. 



ScoJe 



is a measure of how well a given criteria is 
met by a particular alternative. It is 
suggested that scores be assigned on a simple 0 
- 10 scale (or user defined equivalent) . Only 
those items which have weighting factors should 
be scored. 



Weighted Score 



Haxiauni Weighted Score 



Weighted Score/Max Weighted 
Score 



this column entry is the product of the weight 
and the score and is a measure of how well the 
needs of a user are met on that particular 
item, area or module. 

is the product of the weight and the maximum 
possible score. This would be the weighted 
score which implies a perfect fit to the needs 
of the user on a particular criteria item, set 
thereof , factor, etc. 

this ratio gives a proportional measure of how 
well user needs are met on a particular item, 
set thereof, factor, etc. 
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For those evaluators who may wish to compare raw and weighted scores 
across product alternatives, A Detailed Scoring Comparison Form was also 
developed (see Appendix 3). '^his particular form is identical in format 
to the Detailed Evaluation Criteria Form but contains only those items 
which were scoreable (ie. it dees not include context related items). 

2.2 Evaluation Method 

All evaluations were conducted in a school using real and full school 
data. Wb ^ver possible, livf. or current school data was used. When 
this was not possible, data associated with a known reference point was 
used. While the actual testing was performed by programmer or systems 
analysts, school administrators were fully involved with the key 
decisions and judgements which guided the evaluations generally. This 
was one of the most important reasons why the evaluations were conducted 
in the schools. All V^v system capabilities were tested particularly as 
they related to: 

o Data base creation and maintenance 
o Pre-scheduling 
o Scheduling 

o Transition to operational status (and semester turnover) 
o Attendance recording and reporting 
o Progress recording and reporting 
o Report generation 
o Utility functions 

It is not possible to list all evaluation considerations for all citeria 
in this report - some key performance considerations, however, were the 
quality of results achieved, completion times for major procedures and 
reports and inquiry response times . 

Duilng the course of the evaluations, each system was scored against each 
of the evaluation critiera using a zero to ten point scale. Scores were 
assigned as overall measures of "performance" against the criteria taking 
into account all considerations believed to be relevant by the evaluation 
team. 

For example, consider the scheduling process. Both the timing and the 
quality of the result are critical evaluation considerations. 
Competitive systems might receive equivalently low scores if, while one 
produces a high quality result (e.g. high % students completely 
scheduled) in a very long timeframe, the other produces a low quality 
result in a very short timeframe. 

In isolation, the mc^e presence of a particular feature or the sheer 
speed with whicti a process could be completed or the high quality of a 
particular result were not necessarily consistent with the awarding of 
high scores. 

Testing and evaluation was supervised by two different project leaders on 
the Distributed Systems Team (of Edmonton Public Schools' Information 
Services). Every attempt was made to maximize objectivity. 
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Frequent meeangs were held to ensure cross referencing and the sharing 
of ideas and experiences. Despite this, of course, it is reasonaole to 
expect some subjectivity to exist characteristic of the particular 
evaluator • 
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3.0 OVERVIEW OF SYSTEMS EVALUATED 



3.1 The PASS Centred "system 

The software provided by Mid-American falls into two quite different 
categories each of which should be discussed separately. 

1) PROMPT is a data base management and programming tool which is used i.n 
much of Mid-American software as the development language. PROMPT was 
also used as the base for locally developed programs. 

2) The Student Information and Scheduling module known as PASS, standing 
for PROMPT Automated Student Scheduling, is the second component 
purchased from Mid-American. PASS was primarily developed using PRO? 
and as such is easily interfaced to other PROMPT-based software. 

Steps in the evaluation and development incl'^deu: 

- analysis of the scheduler characteristics and the initiation of 
essential customizations. 

- initial testing with "clean" data for which results were known. 

- development of a Pupil Records database to replace the minimal one 
included with PASS. The design of this database was focussed on EPSB 
type data structures . 

Initial testing proved largely positive and led to the development of a 
period by period attendance system which was integrated with the pupil 
records and student scheduling components. The attendance system was 
initially tested under operating conditions in January 1984. Some minor 
modifications were effected and the system went into in full use in 
February 1984. This included the pupil records maintenance of demographic 
data transfers in and out and changes in students timetables. These items 
were necessary to maintain since this file is the basis for the attendance 
system. Changes which were made to the Series 1 data base at Jasper Place 
were captured and transmitted to the mainfraire for updating there. It is 
important to stress that not all school districts would have a requirement 
to update a "mainf rame'^computer but telecommunications would still be 
required between central office and schools. 

Scheduling for the 1984/85 year was done using the Mid-American PASS 
system along with the locally developed database updating procedures. 
Initially, parallel runs were done on both mainframe and minicomputer but 
as results were verified and shown to be consistent, the minicomputer 
became the active scheduling system. The various reports used for school 
opening were generated by the minicomputer system. These included student 
and teacher timetables, class lists, school directories and ID cards. 
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Student timetables were transmitted to the rac:.infrarae for updating the 
district data base. The files were ready for attendance input on the 
first day of school and the scheduler was kept open in order to schedule 
late registrants. This minicomputer system is currently in use at Jasper 
Place and is the primary system for attendance and student timetables 
generation. Progress reporting is still done on the mainframe with 
attendance data and timetable changes transmitted to the control site. 

3.2 SAS 

The SIERRA Software Systems Student Administration System (SAS) package 
was developed on a Digital Equipment VAX 11/750 minicomputer (a fairly 
large and powerful comouter) as a centralized timesharing system for use 
by a number of schools. Two demonstrations of the SAS package were 
attended by Distributed Systems Team members and based on investigations 
and these demonstrations a VAX 11/725 computer ( a very much smaller 
machine) and the SAS package were purchased. The system was installed at 
Jasper Place Composite High School in October 1984 after approximately one 
week of system software and configuration work. After a short "hands-on" 
learning phase, a formal 2 day ;:raining course was provided by SIERPA 
(Octc : 29th and 3Cth, 1984). 

The software provided by SIERRA incorporates all of the main features 
required in a School Information Management System: Student records, 
scheduling, attendance and progress/marks. It was therefore decided that 
the main thrust of the evaluation would be to test the system with a full 
set of school data; develop data transfer software to automatically load 
the database from other computers (mainframe, mini-and micro-) and develop 
reports using the report writer package provided. The testing plan 
outlined three main phases of work: 



Phase I: Configure the VMS Operating System and SAS package, set up all 
static data, set up 168 Grade IK (pre-Grade 10) students and 
schedule them. 

Phsse II: Develop software to download all 1846 student records and 

15,000 course requests from the district mainframe computers. 
Edit records as necessary, build a full master schedule. 

Phase III: Obtain the best possible schedule for all students, produce all 
necessary reports (e.g. timetables), load students into 
classes, design and develop reports as necessary, tes^: 
attendance and progress f unc ions . 
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All three phases were completed as planned, the only exception being that 
mainframe downloading was carried out via an IBM PC computer rather than 
directly from mainframe to VAX* 



The work was completed in February i985« 

SIERRA^ is based in Vancouver and provides centraliz^^ ' time-sharing as 
well as distributed system services. \ number of school districts in 
British Columbia use the SAS packag . an ^ there is a fairly wide user base 
in the Northwest United States. 



SIERRA is now part of a larger g:oup of companies called Computech 
Limi^^^d • 
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4.0 PRODUCT EVALUATIONS - SENIOR HIGH SCHOOL ^ ^ECTIVE 



As stated previously, the PASS and PROMPT systems were evaluated at a 
senior high school on an IBM Series 1 minicomputer. The following sub- 
sections describ ' the product, development tools, softv/^re de^^^eloped by 
Edmonton Public Schools, the testing environment c.nd results of 
evaluation, 

A.l Evaluation of the PASS Centred System 

4,1,1 Product Description 

PASS 

The PASS system or PROMPT Automated Student Scheduling is a system written 
in PROMPT language with some of the more time conruming (CPU bound) work 
like scheduling students and conflict analyses subprograms written in an 
assembler like language, EDL, which executes more rapidly. 

The <?vqtem is composed of 3 main parts which parallel the chronological 
steps preparing a school for start of the year operation. 

Part I 

Part I is primarily concerned with getting student information into the 
sy*?tem along with course selections. This is provided by input of a 
course catalogue or course offering file, a list of directions against 
which student requests are validated. The student demographic information 
is minimal including little more than name, address, phone, birthdate, 
sex, grade and a few other fields. This is basically just the information 
which would be required for scheduling a student and corresponding with 
the student and or parents. Certain reports such as ''course requast 
tallies", are necessary for building a master schedule and "potential 
conflicts" and "pc^^ ^minary rosters" are produced in this phase along with 
reports used to edit and clean up the student and course request files. 

Part II 

Part II includes the data entry of files and procedures necessary in 
establishing the school master schedule. Master sched^ile entry is 
facilitated here and editing of valid courses, valid teachers, and 
sequent!:?! sections of cours' ^ is done at data entry time. Once the 
master has been entered then two special reports can be generated showing 
instructor conflicts and room conflicts. Any modifications based on these 
reports can be made and a hard copy of the master schedule generated. 

Part III 

This is where the actual schedu ing of students is initiat-^d. The 
scheduling procedure is designed so thai a number of runs can be done 
using various condiL"*ons such as specific grades only, overfill classes or 
not, and allow partial schedules or not. Each time the scheduler Is run 
those students not scheduled are picked out and a timetable is attempted 
to be found for each. The optioi also exists to clear out all timetablts, 
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set counts in each class to zero, and start again from scratch. Each 
scheduling run provides aucomatic statistics as to how many students were 
scheduled and how many were not. After a scheduling run, various reports 
may be generated, some of which are student timetables for the last group 
scheduled or for all students or for students with conflicts and master 
schedule tallies to see how classes filled up. The option also exists to 
get a report of students with free time and to use study hall generation 
as a way to deal with the free time issue. 

Hard scheduling of students and/or changing classes assigned to a student 
may be done at any time. The final part of this phase is the generation 
of student schedules, teacher schedules and class lists. 

A number of modifications to this package were made in order to better 
reflect the data and operational environments at Jasper Place in 
particular and Edmonton Public Schools in general. These changes were 
possible since most of PASS is writcen in PROMPT allowing the team to 
modify software as we have both the tools and expertise. 

Conflict Report 

The conflict report as delivered contain-^d a large amount of unnecessat 
information (lists of pairs of courses th no conflicts) and a format 
where the really important information ^^es difficult to extract. Changes 
w^.e made to allov^ conflict renorts on » ''<5letons'* only and "singletons'* 
and "doubletons" together^ All zero's ^*_rr excluded from the report and 
the remaining non zero entries were rank-., rrom highest co lowest 
number. These changes resulr3d in ? more compact ari easier to read 
report . 

School Reports 

The reports for school scheduling were significantly changed. Student 
timetables were produced on EPSB preprinted forms In both grid and tabular 
form,. Teacher timetables were produced in grid form for each semester and 
class lists were produced ci EPSB customized forms. 

Pupil Records Database 

The pupil records area was altered in a different way. A new data base 
was created separately from the one included in PASS. This data base 
reflected the needs and coding conventions currently usel witliin the 
district. Programs were then written to interface between this newly 
developed pupil records database and the pupil records required for input 
to the scheduler. The output of the scheduler was again converted iiito a 
format which was determined in the new data base. More information on 
this development is included in the next section of this report. 



PROMPT is a data base management tool which allows the user a great deal 
of f lexj bill ty in the design , programming, and implementation of an 
appl j cation . 



PROMPT 
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File Creation 



Specification of a File Control Block or FCB allows for the definition of 
a file structure and formatting of a data entry screen if desired. The 
characteristics of the file are stored and many files with these 
charactertics may be created. 

File conversion specifications may be used to convert files of one format 
to another. This is very useful if a FCB needs to be changed as all data 
under the old FCB can be converted to the new. 

File amend specifications may be written to amend the contents on any 
file. Each amend specification can specify which fields may be changed or 
not changed or displayed only. Multiple amends can be written for any one 
file with varying degress of changes allowed, that is one person could 
?:nend certain fields whereas another could amend different fields. 

File inquiries and reports may be written to display certain fields of a 
number of files in a programmer defined format. Each report and inquiry 
is scored and may be used with a number of different files. 

The existence of "processors" allows the programmer to write specific 
programs to enable processing which is not covered in the PROMPT 
facilities. This allows some very customized processing and gives a large 
amount of flexibility to the programmer. 

The true power of PROMPT is found in the menu creation facility. Here 
most of the items on the data base facilities screen and other programs 
can be embedded in a menu and activated by that menu. The operator at a 
screen sees only the menu selections and the programmer Vias total control 
of the job-streams defined by the menu. 

Th(i management system also includes a number of other standard data 
pr')cessing tools such as sorts, merges, extracts, copy, etc. 

PROMPT has now been used for over a year and a half at this site and has 
shown to be very reliable and error free. Enhancements are being added to 
PROMPT along with a number of special supplementary tools which will 
overcome some of the recognized, current limitations. Mid-American is 
also undertaking a major rewrite of PROMPT where the file structures will 
be based on relational database concepts. 

Distributed Systems Team Developed Software 

Database Development 

In order to test and implement the scheduling component of Mid-American 
software, it was necessary to design a pupil records database which would 
allow for data to be received f**om and sent to the mainframe and to allow 
for passing data through conversion processes to the scheduler and 
bringing scheduling results back. Thi^ local database was developed after 
a careful analysis of the scheduler (PASS) requirements, the school 
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operational require^ients and the mainfran^ requirements and 
restrictions. The major files are a student demographic file which is 
keyed on a six character local school defined student ID which is cross 
referenced to the mainframe student ID and the scheduling ID» The fields 
were defined to handle the attributes of the data currently considered 
important and with expansion space if the need arises. There is one 
record for each student. The second major file contains the student 
timetable information with areas reserved for attendance and progress. 
This is a multiple record type of file with one record for each course or 
class a stud3nt is taking. The class and section numbei identify the 
class and link to the master scheduler file where information on course 
titles, periods, semesters, rooms, teachers, credits etc. are kept- 

In close conjunction with these files is a system of maintaining each file 
and producing edit type reports and/or screen messages which reflect the 
file changes. Areas of development included adding or deleting students 
from the file (deletions actually go to another area 'or storage since a 
student may return), changing any of the demographic data, changing 
timetables, and capturing many of these changes for transmission to the 
mainframe. Also a number of different inquiries have been developed to 
allow for screen lookups of student timetable attendance information or 
demographic information. A number of reports have been designed to 
reflect the school requirements; among these are school directories, class 
lists, master schedule list and various cross reference reports. 

Attendance System 

An attendance system using PROMPT has been designed, programmed, and 
implemented by Distributed Systems Team staff. Major design criteria 
were : 

- period by period attendance capturing 

- minimal data entry 

- user defined reason codes 

- timely generation of daily attendance exceptions (excused, unexcused) 
two week attendance summary for every st^jdent and every class. 

The attendance systeip is in current operation and has been so for over I 
year. Student and class information is totally integrated so that at any 
point in time attendance information is posted into the proper record. 

Typical daily operation would begin with amending any entries from 
previous days which were incorrectly updated. Entry of current day 
absences as reported Ly teachers, preferably in batches by period. This 
process is intermixed with excused absence entry throughout the day due to 
parent phone calls, student reporting or school activities such as field 
trips. Any excused absence codes are held and logically matched to 
reported absences from class. The end of the day procedures generate a 
report <^howing excused absences by students with excuse code for each 
period, a report of students with any unexcused absences for any period 
and a list for school distribution arranged alphabetically of all students 
with unexcused absences. 
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Detailed attendance information is kept for 2 weeks, then is summarized 
for each student for each class and a master report for the whole school 
is produced. Attendance information which is required for progress 
reporting is transmitted to the mainframe. 

The success of the testing and implementation of the attendance system 
have resulted in the school discontinuing use of the mainframe based 
attendance system. Single transaction capturing at the current time has 
replaced the old system, and streamlined anl made more efficient the 
capturing and reporting of attendance data. 

Communications Systems 

The need for information to be consistent with the mainframe in a timely 
way has brought to the fore a need for some means of communication between 
the central mainframe and the school based minicomputer system. 

The data base design and updating procedures design were undertaken with 
this requirement in mind. The actual communication software chosen was a 
Remote Job Entry (RJE) program running on the Series 1 a d a matching 
program on the mainframe. To facilitate a two way communiv. ^-ion custom 
programs were written in COBOL on the mainframe and in PROMPT the 
minicomputer end. These programs allowed for extracts from the mainframe 
followed by logical updat(.o at the minicomputer end and extracts of 
transactions from the minicomputer end sent into the regular mainframe 
update jobstream. Student demographic data and course requests were 
transmitted from the mainframe to the minicomputer and timetable changes 
and attendance data were transmitted from the minicomputer to the 
mainframe. 

Because of a decision to schedule Jasper Place on the mainframe and on the 
minicomputer, programs were developed to transmit, through conversion 
jobstreams, the master schedule in both directions. This allowed changes 
in the master schedule made at eirher machine to be reflected in the 
other. A side product of this process was the ability to get a very clean 
master schedule as so many checks were made in the conversions that almost 
any anomaly was quickly detected and corrected, 

A , 1 . 2 Testing Environment and Conditions 

The hardware environment for testing and eventual implementation included 
the Series 1 with 384K core divided into 6 partitj^ons, a 63 megabyte hard 
disk drive, 1 floppy diskette drive, I bisync communications card with 
appropriate modem, three 3101 terminals, one IBM PC with terminal 
emulation software, and one 4974 200 cps printer. See Appendix 4, page 2 
for the physical configuration. 

One terminal located in the main office was used solely for attendance 
system purposes. The console terminal described as the centre for pupil 
records updating and large report printing and the two remaining terminals 
were used primarily for programming and system monitoring. 
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Experience showed that careful planning of job submissions was 
necessary. If two terminals simulraneously initiated tasks which were 
heavy in processing {CFU bound) then response time on any terminal became 
unacceptable. However, four terminals could all be functional if each was 
engaged in inquiries, or data ei\try, or report writing, or other non 
intensive routines. 

Data entry of attendance information is made at one point only and then 
sent to other areas where required. This includes mainfr,amo uploading. 
Student timetable changes are also entered only once with Lransacticns 
captured and transmitted to the mainframe for update there. However, 
certain data has had to be double-entered, this includes information such 
as registering new students and deletion of students. 

Printing of reports has been a problem especially for long reports where 
multiple copies are required. A prime example of this is the two week 
attendance report which shows every student and their attendance record in 
every class. The report is 275 pages long anc'. takes about 5 hours to 
print which means in total 20-25 hours printxag. Over night printing has 
been only partially successful as many times, • -er jairs seem to occur and 
printing during the day tends to hold up othe. cessary jobs. 

The scheduling testing and implementation has spanned 2 scheduling years 
1983/84 and 1984/85. During the 1983/84 year the mainfiame scheduling was 
the primary operation with the minicomputer playing a tracking role. 
Errors were found in some of the schedules produced by Mid-American and a 
decision was made to use the mainframe results. During the 1984/85 
scheduling procedure the minicomputer became the primary system with the 
mainframe in a backup role. Confidence grew in the Mid-American schedules 
and the number of parallel runs decreased. Jasper Place opened using the 
minicomputer schedules and these timetables were tranmitted to the 
mainframe in ear"'y September. 

4.1.3 Evaluation Results and Observations 

The following tables show the Quantitative evaluation of the PASS centred 
system against the detailed criteria. 
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EVALUATION 
FACTOR 



CRITERIA ITEMS 



PRODUCT 
SCOPE 4 
FUKCTION 



SCHOOL RECORDS 

Pre"P?gl8tratlon/EnrollTw>nt 
Create student record 

- school student I.D, ! 

- last name | 

- middle name | 

- first name \ 

- birthdate j 

- current grade j 

- sex j 

- feeder school i 

- home address 

Registration confirmation notice 
Feeder school confirmation notice 

TOTAL Pre-Reglstmtion/biroUjnt 
Detailed Data Itero 



Student informtion 

- school student I.D. 

- District student I.D, 

- Alberta Education student 1*D. 

- lw«st name 

- middle name 

- first name 

- birthdate 

- current grade 

- sex 

- feeder school 
" home address 

- telephone number 



WEIGHT 
(W) 



15 



SCORE 
(S) 



WEIGHTED SCORE 
(W X S) 



135 



MAX Vr SCORE 



20 



13/30 



Wr SCORE/MAX VT SCORE 



144 



200 



.72 



03 



25 



200 



50 



EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX WT SCORE 

(W X S ) 
max' 


WT SCORE/MAX UTT ^CDRF 




- emergency contact 

- name 

- telephone 

- entry Informal ion 

- entry date 

- registration code 

- withdrawal code 

- previous schools (2) 

- toroeroom instruction 

- counsellor 

- parent/guardian information (up to 4) 

- name 

- address 

- telephone (home and business) 

- relationship 

- occupation 

- locker inform2«"ion 

- number 

- ::ombination 

- student indebtedness 

- religious denomination 

- program type 

- number of credits earned 

- this school 

- other schools 

- academic history 

- travel information 

- method 

- distance 

- bus pass information 

- parking information 

- driver's licence 

- licence plate 

- parking space 

- medical Information 

- disabilities/behaviours 

- medications 













EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


SCORE 
(S) 


! WEIGHTED SCORE 
(W X S) 


MAX WT SCORE 

(W X S ) 
max' 


vrr SCORE/MAX vr score 


1 


" date of last medical 

- physician information 
" health care number 

- departure information 

- date 

- reason 

- minimum of 6 user defined fields 














Instructor Information 


5 


3 


15 








- instructor code 

- name 

- address 

- telephone 

social insurance numoer 

- language of instruction 

- certificate number 

- courses taught 

- minimum of 6 user defined fields 














Course information 


15 


6 


90 








- course code (5 character alpha-numeric) 

- description 

- pre-and co-requisites (mininum of 4) 

- must handle "and"/"or"situatlon 

- course type 

language or iusl ruction 

- course accreditation 

- creait value (2 digits) 

- pass/fail mark 

- grade 














TOEAL Detailed Data Itev 


45 


17/30 


305 


450 


.677 


52 
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EVALUATION 
FACTOk 



CRITERIA ITEMS 



Reports/Inquiries 

All reports and inquiries should be ^^vail- 
able .^or all or a specified range of 
records, in various sort orders. 

- class lists 

- homeroom ?l3t8 

- student iiane labels 

- student address labels 

- parent address labels 

- student I.D. cards 

- student data (alphabetical or numerical 
order) 

- parent data (alphabetical or numerical 
order) 

- instructor data (alphabetical or numer- 
ical order) 

- course data 

- student rhone list 

- student »<ane list 

- student grade list 

- feeder scJkxI list 

- locker information list 

- student population by instruction L^pe 

- fee sheets 

The system should allow production of 
user^-defined ..eperts/inquiries using 
available data. 

TOUL Reports/Inquiries 

TUTAL SCBOOL RECORDS 



WEIGHT 
(W) 



25 



SCORE 
(S, 



25 



90 



38/70 



\ 

WEIGHTED SCORE [MAX WT SCORE 
(I) X c) (w X S^,) 



200 



200 



649 



2S0 



900 



Wr SOURE/MAX WT SCORE 



.72 
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EVALUATION 
FACTOR 



CRITERIA ITEMS 



SCHEDULING 

I Detailed Data Items 

- Course code 

- Course section 

j Manual scheduling (Arena Scheduling) 
j Pre~scheduling 

f Course Requests 

I 

j manual entry 

, automated entry 

- allow student to specify mandatory/ 
compulsory courses, 

- preferred courses, preferred 
alternatives, etc. 

- allow s^rudent to specify preferred 
section, semester, or instructor 

Edit and vallda^ion of course requests 

- checking of pre- and co- requisites in 
the current students* requests as well 
as history files 

- capability to override pre- and co- 
requisites 

- capability to complete pre-requisite 
c>iecking for students C^um other 
District schools. 

Pre-scheduling reports 

- potential contlict matrix — for all 
or a specified range of courses. 
Additional selection criteria may be 



56 



WEIGHT 
(W) 



SCORE 
(S) 



WEIGHTED SCORE 
(W X S) 



MAX Wr '^CORE 



49 



WT SCORE/MAX Wf SCORE 



40 
27 



28 



63 



J 

5? 



55 



EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX WT SCORE 


WT SCORE/ MAX WT SCORE 




based on the number of requests or the 
number of sec i ions. 

- course tally 

- students with no requests 

- s;:udent course request list 

- Tnin/m?*^ request list 

- mln/may credit lisc 

- verification tickets 

- arena scheduling labels 

- students missing compulsory courses 

- students requesting specific course or 
group of courses 














Master schedule builder 














Capability to build a master schedule 
manually 


6 


7 










automatically 


9 


0 


— ~ 

0 








Capability of handling a variety of 
Schedul ing units 


9 


3 


27 








- full year 

- semester 

- trimester 

- quar termester 

- 6 week unit 

- any combination of the above 














User defined timetable rotation/tumble 


10 


3 


30 








Flexible number of periods per day 


10 


8 


80 








Capability to specify exclusive male or 
fenale sections 


5 


8 


40 








Ca^ ability to maintain current and future 
year/sfmester /wstec schedules 


8 


8 
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EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 


SCORE 


WEIGHTED SCORE 
(V X S) 


MAX Wr SCORE 


WT SCORE/MAX WT SCORE 




Scheduling Process 














User defined scheduling sequence 

- low grades first 

- high grades first 

- A to Z 

- Z to A 

Unscheduling of no-shows /withdr^vals 

Scheduling of individual student or irmall 

groups of students 

Capability to reset all students or 

partially scheduled students 

Capability to loch scheduling assignments 

for all students or a group of students 

Restart capability 

Course weighting/semester balancing 

(ensure even course load for sr^-dents) 

Blocking of courses 

Section balancing 

Class balancing fmales— fpTTM1pc^ 

Capability to keep scheduling open after 

school start while starting to use the 

attendance module 


0 


n 

y 










5 


9 


45 








0 


b 


36 










0 


0 








Q 

O 


2 


16 








o 
O 


0 


0 








8 


8 


6A 








7 




28 








8 


8 


64 








/. 


8 


32 








9 




36 








Scheduling Reports/Inquiries 


10 


8 


80 






GO 


student timetables — grid and list 
format 

- instructor timetables ~ grid and list 
format 

- room tlmetiibles — grid and list format 
iiiris> Lci scneQuie 

- student scheduling conflicts 

- students partially scheduled 

- unassigned time 
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EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX Wr SCORE 

(W X S ^ ) 
max 


SCORE/MAX Vrr SCORE 




Junior High SchtJuline; Reqj!^_rements 














HonierooiB grouping for core subjects 














Capabil ty of scheduling any course In 
any corabi nation and number of time 
periods 














TOTEAL SGUEDULIIC 


181 


i26/2A0 


945 


1810 


.52 




SrUDENT AITENDAN(2 














Entry of Attendance Data 














manual entry 


5 


8 


AO 








automated entry 


9 


0 










Multiple user -defined absence types 


8 


8 


64 








Capability to record attendance data at 
various intervals 


10 


8 


80 








- dally 

- twice per day 

- period by period 

- subject by subject 














Attendance history 


8 


8 


64 








- at least ten days detail 
" cummulaCive totals 














Attendance reports/inquiries 


10 


8 


80 








- studeiit by class 

- student by subject 

- studert by period 
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EVALUATION 
FACTOR 


CRITERIA ITEMS 


(W) 


(S) 


Wr<iOnlc*u ouUKt 
(W X S) 


MAX WT SCORE 

(W X S ) 
max' 


wi SCOKb/MAX WT SCORE 




- homeroom attendance 

- dally summary 

- weekly summary 
~ monthly summary 
~ multiple absence 

~ capability to produce un <cused 
absence report for the current day 
vdthin 30 minutes 

- the system should allow user defined 
reports/inquiries using available data 














TtTEAL ATTENDANCE 


50 


40/60 


328 


500 


.656 




SnUDEKT NARKS 














Entrv of nvirkc; d;irA 














manual 


5 


0 


0 








automated 


3 




u 








Marks data 


10 


0 


0 








- minimum of A term marks plus final mark 

- letter or percentage grades 














Student Exams 


6 


0 


0 








Exam timetable builder 














- automated 

- nkinual 














Exam Repcrts/Inqulrles 














- potential exam conflict matrix 

- exam schedules 
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EVALUATION 



CRITERIA ITEMS 



Rcporte/Inqulries 

proof list 
report cards 

- marks data 

- final mark, calculated according to 
user-defined formula attenandance data 

- class averages 

- honour lists 

- potential failure lists 

- graduation list 

TOnCAL STODKNT MARKS 



OTILnT FUNCTIONS 

Backup/Restore 
Security/ Controls 
TOTAL UTILm PDNCnONS 



GRAND TOTAL, PRODDCT SCOPE 
AND FUNCTION 



EASE OF 
USE 



- flexibility 

- modular, table driven 

- help facilities 

- menu driven 



60 



(TAAND TOTAL, BASE OF USB 



WEIGlfr 

(w) 



SCORE 
(S) 



WEIGHTED SCORE 
(W X S) 



MAX WT SCORE 
X S^) 



1' SCORE/MAX Wr SCORE 



10 



381 



60 



212/4m| 




60 



40 


0/50 


0 


12 


6_ 


72 


8 


2 


16 


20 


8/20 


88 









2010 



300 



] 



300 



400 



200 



3810 



600 



0 



.44 



.5276 



67 



EVALUATIC*^ 
FACTOR 



TECHMICAL 

OCMSIDCifiATIONS 



o 



SUPPORT & 
SERVICSS 



68 



CRTTEIIA ITL-MG 



WEIGHT 
(W) 



- hardware 

- System software environment 

- operating system 

- utilities 

' database management/sybtein 
internals/files 

- networking capabilities 
~ user hooks 

~ modularity of the system 



GRAND TOTAL, TECHNICAL C NSlDEP/riONS 



local versus where/how far 
package support and services 
' softwart* supoort, custom 
modifications 

documentation 

~ user guide, application syste^r, 
procedural, 'Operations guide, 
file layouts 

training 

• applications system, operational 
(DP), availability schedule, 
format, location, pi^requisites 

implementation 

- training 

- initialization (conversion, file 
set-up, ou put forms) 

- implementation plan 



GRAND TOTAL, SUPPORT h SERVICES 



80 



SCORE 
(S) 



WEIGHTED SCORE 
(W X S) 



80 



70 



70 



320 



3*X) 



350 



MAX \n SCORE 



800 



350 



700 



V/T SCORE/MAX VTF SCORE 
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EVALUATION 
FACTOR 



CRITERIA ITEMS 



PRODUCT 
qUALIFICATIOKS 



- package background 

- reliability 

- current development status 

- number of installations 

- product development plans 

- release concept, portability, 
verticality 



GRAND TOTAL, PRODJCT Q«?ALIFICATICHS 



- Corporate information 

- barkground and history 

- financial performance 

- employee base 

- Market volatility and vendor stability 

- References 

- Contractu^^l Terms 

- maintenance 

- warranty 

- ovmership rights 

- discount structu*"e/price limit 

GRAND TOTAL, VEKJOR 



7U 



WEIGKT 
(W) 



80 



80 



70 



SCORE 
(S) 



70 



WEIGHTED SCORE 
(W X S) 



560 



560 



560 



560 



MAX UT SCORE 



WT SCORE/ MAX VI SCORE 



9CQ 



700 



.8 
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Observations 



For each or the six major evaluation factors, the following comments and 
observations are offered in support of the quantitati\e evaluation of the 
PASS centred system. 

(a) Product Scope and Function 

The Mid-American package is not well zv^tf-d to L? rated -yased or. the 
criteria items since this ic primarily a development system and developed 
within our environment. Th; s means that the areas sucn as student 
demog-aphic information and reporting would rank highly whilst areas such 
as progress reporting will not rank at all since these have not been 
developed. However, an attempt has been made to complete the rating forms 
in accordance with fully developed packages. 

Genera ^y the Detailed Student Data will rank quite high since the 
database was designed with most of these data elenents in mind. Also 
since PROMPT is used the data base is very easily expandable to include 
any of the other pieces of data which were deemed necessary. Instructor 
information is minimal at present and designed only for scheduling 
purposes. Again this could be easily expanded. Course information is 
generally acceptable except for lack of any pre-requisite and/or co- 
requisite capabilities. Approximately 60% of the listed reports are 
present, however, since using PROMPT any custom report could be generated. 

The scheduling module handled all situations which the mainframe could and 
generated some extra useful reports such as teacher timetables, and 
teacher/room conflicts and had the capability to schedule small groups of 
students O' those already scheduled. A number of extra features were 
not present or did not perform well. These included inabilicy to deal 
with combinations of quar termester and trimester mixes, inabilitv to 
handle very scattered course meeting times, difficulty in linkinp; courses 
during scheduling, and inability to handle pre-requisite situations. 

Th€ SLudent attendance system rated highly as it was designed to meet the 
needs of schools within .^ur district. The main negative area was the lack 
of automated data input. 

The student marks function is rated zero since no development has been 
done in this ?rea. 

(B) Ease of Us e 

The use of PROMPT as a developi^ient tool has aUowed a great deal of 
flexibility at both th^ programming level and at the user level. The user 
or operator sees only application menus which can be defired and 
maintained using PROMPT. Menus can call other menus thus a hierarchial 
structure may be developed. 
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(C) Technical Considerations 

The Series I and primary operating system EDX aie not reknown for user 
friendliness. A certain amount of programmer or operator level suppoit is 
requi»:ed to keep the system in prime running order. PROMPT deals 
primarily with Indexed Sequential Files which tonds to lake jobsteams run 
slowly due to the constant need for sorting and indexing. As jobs are 
processing the screen constantly displays a sequence of job control 
l^^guage type statements which are meaningless to the normal user. 

(D) Support and Services 

With Mid-American situated in the mid eastern part of the United States 
the distance at times a problem as well as the inconvience of dealing 
across country borders. Several times exchange of software, data and 
information has been delayed due to customs reiuiremei.cs. 

Mid-American has been very conscious and receptive to problems due to 
software errors and has sent patches ^_ad updates as rapidly as possible. 
They also maintain a support system by phone and are usually quite rapid 
in solving problems. Ti.-ainiug sessions are held periodically for various 
levels of PROMPL training. Support for the IBM Series 1 has been weak 
since there seems to be no local Series I expert. Both the Series 1 and 
Mid-American -^ograms have quite extensive documentation. 

(E) Product Qualifications 

PROMPT h.is been available sii e 1976 and soon version 10 will be rt leased 
which w:.ll show several major enhancements. The PASS system has been 
expanded to include grade reporting and attendance modules. 

PROMPT has been a very reliable product with no evidence of system bugs. 
The PASS system has had some operational problems due to software errors, 
however these have been resolved. 

(F) Vendor 

Mid-American Control Corporation is the developer of PROMPT aid PASS along 
with a number of other application software p.ickages including financial 
and inventory systems. The company has an employee base of 30 or more 
people and is currently expanding its physical premises in order to meet 
the needs of expanded growth. 

Student Administration systems are being continually nonitored and 
enhc'^nced. Currently, a major programming activity is the evolution of 
PROMP;^ from an indexed sequential file based system to a true relational 
data bc^se system. 

The romp.^ny also has a number of der-^lers scatuered throughout the USA, 
Canada, aid Europe who sell and provide initial support for their software 
packages . 
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A. 1,4 Syst em Performance, Strengths and Wejknt-sses - [-ASS Centred System 
Kev Performance Indi' ators 



School Test Site 



Jasper Place CHS 



Parameter 
Scheduler - Tim3 
Scheduler - Performance 
Scheduler ~ Expected Perf. 



Re^-ul t 
8:30 hours 
85% 
85% 



Timetables 
Conflict Matrix 
Course Tally 
Master Schedule 
Class Lists 
Attendance Regi sters 
Student Registers 



23:00 nours (grid) 
S-'^O hours 

0:50 hours 
7:0U hours 

1:15 hours 



Jasper Place CHS 



i8'-t ) students 



(All timi ngs are in hours :ni nutes ) 
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System Strengths; 



1. Totally user defined in terras of fields and files and reports (Thus 
systera is user alterable). 

2. Scheduler loaded classes very well and raade partial schedules by 
leaving out the least significanc courses e.g. corapulsoiy or core 
courses are placed before options. 

3. Transaction capturing in place for certain types of transactions such 
as stude.it progress records. This raeans tha«" updating the raainfrarae 
file is through changes rather than overwriting the whole file. 

4. Systera is raultiuser, 

5. Scheduling with partial schedules prints the appropriate courses fi.om 
raaster schedule to enable the adrainistrators to raanually resolve the 
conflict. 

6. Communication with the raainfrarae is established though a fair araount of 
polishing is .equired to make it custoraer usable. 

7. Prints on various iTorms which have proven useful over raany years 
(flexible repo;.t writing). 

8. The attendt:.nce systera has sorae intelligence, rather than strictly 
capturing data. It can handle special requireraents such as unreported 
absences and field trips. 

Systera Weaknesses: 

1. Systera requires a fair amount of prograraraer type support in its present 
state and would always require a sraall araount. 

2. Inefficient use of hardware, i.e. several processes running at the 
sarae tirae really irapact the systera, response tirae becomes unreasonable. 

3. Student Records Systera not fully developed at present. Progress 
Reporting is absent and other systeras would require refining. 

4. High hardware and software costs. 

5. Little user type docuraentation currently written. Refining type 
changes would need to be corapleted before a serious effort in 
documentation was initiated. 

6. No history segment within data base. For opciraal use a pre-requi si te 
checking systera wculd need to be deve? ^ped at the sarae time* 
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^•2 EVALJATION OF SAS - SENIOR HIGH SCHOOL PERSPECTIVE 



The following sub-sections illustr- a the details of the product, 
Distributed Systems team developed components, the environment in which 
testing took place, detailed evaluation tables and related resulis. 

4,2. 1 Product Description 

SAS 

The Stuaent Administration System is a fairly large, modular package of 
programs. It is written almost entirely in VAX Basic and is compiled for 
speed and efficiency. There is a very small amount of assembler code and 
a few hundred lines of job control language (called DCL - Digital Command 
Language). The package works with the standard VAX database system - RMS 

- but does not utilize the file layout or utilltips ulfhin ms. Thus, to 
the RMS database management system each file record consists of 2 fields - 
key and "Filler'*, 

The Student Administration System consists of several components which can 
be used by the school(s): 

- School Initialisation 
Student Records 

- Scheduling 

- Division Assignments 
Marks Administration 
Attendance Checking 

- Year End Reporting and Maintenance 
Government Reporting 

- Miscellaneous Reporting 

The components can all be operated from tue same terminal located in a 
school office. 

At the scnool, the user interacts with the application system using one or 
more terminals. One or more printers are used to produce repo and 
labels. The printer and terminal can be connected locally, or, wuere a 
number of schools share one VAX minicomputer, via a modem to the central 
computer site. 

The application system is modular and interactive using a series of 
heirarchical menus and active editing and validation of data as it is 
entered (field by field editing). A number of BASIC run-time library 
messages were displayed due to program crashes oi user errors but in 
general, the system is user triendly with some on-line help and 
considerable flexibility in terms of "routes" to a particular function. 
Report requests gent^tate spooled reports which have to be released from 
the system spooler by a series of VAX/VMS commands; this was considered to 
be overly complex and would require application users to learn a fair 
amount about the VAX/VMS operating systems. 



ERLC 



(45) 



Ill addition to the application system, the part the user :S ^ there are a 
number of components available for the system and application 
programmer. ADE is the Application Design Environment and is a set of 
development tools which help the application programmer develop reports 
(it includes a sophisticated report writer package). There are programs 
for interfacing with other computer systems and data management 
programs. The System Manager Software provided facilities for managing 
the database, the interface with the Operating System, overall priorities 
of applications, timing parameters, batch and printer queues and system 
tables. The generation software is a series of job control files used to 
set up the application system and database files and initialize the school 
parameters. 

User documentation is very comprehensive and structured; it comes in a 
plastic binder with a Central Users Guide (System Managers Guide) provided 
in a separate binder. The user manual provides an overview of the 
application system followed by a series of diagrams showing the 
operational cycle and detailed sections on each function. The Central 
Users Guide lists the various "hidden" screens available to the system 
manager for controlling batch queues and resources and setting record 
pointers and other internal parameters. 

Distributed Systems Team Developed Software 

The purchased software, while providing all of the nain Student 
Information facilities was found to be deficient in two areas: data 
loading from external sources and reports. Software was developed by the 
Distributed Systems Team in these two areas as part of the evaluation 
study. This work mirrored similar developments in the evaluation of the 
PASS centred system. 

Data Loading and Transfer 

Student demographic data and course requests were derived from IBM Series 
1 and 4341 computers. It was decided to automate the transfer of data 
because of the large volume of information involved and the need to 
eliminate punching and other manual errors. An IBM PC microcomputer was 
connected by a serial line to the IBM Series 1 minicomputer and used to 
extract data and merge it from 3 record types to produce student 
demographic records. Similarly, course request records were extracted 
from the Series 1 computer and modified on the IBM PC. Data was then 
loaded from a DEC Rainbow (IBM PC software compatible) microcomputer to 
the VAX minicomputer where it was reorgan'zed into RMS database records. 
Appendix 5 lists the processes involved in detail. 



A number of key reports were found to be either absent (not listed as menu 
options or "unavailable" when requested) or failed to work. The most 
critical area where th-^s problem occurred was in the setting up of che 
*^ tatic and control parameters. At this stage , instant feedback is needed 
in the form of directory or edit listings of, for example, rooms, 
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teachers, absence codes and program codes- At a later stage in the 
evaluation process, detailed reports weie needed from the course and class 
master files. 

Ill both cases a number of reports were developed using the report writer 
package Provided by SIERRA, Although rudimentary (it only works with a 
single daua hase file) and fairly complex, the package was found to be 
ideal for obtaining full single file reports. A more sophisticated report 
writer is under development. This is not intended to be a programmer's 
development utility. 

^•2'>2 Testing Environment and Conditions 

Testing of the SAS package was carried out at Jasper Place Composite High 
School between October 1984 and February 1985. The testing environment 
was a 2 megabyte VAX 11/725 minicomputer with twin (one fixed and one 
cartridge/re. oveable) 25 megabyte disc drives, twin cartridge tape units, 
two DEC Rainbcw 100 microcomputers connected as terminals (one equipped 
with a local I A50 printer), an LAIOO 300 cps printer and a VT220 system 
terminal. Initial ^etup, intialization of database files and creation of 
static parameters, pre-grade 10 students and course requests was done by 
manual data entry. Full testing of all students and course requests was 
accomplished with data loading via che Rainbow 100 computers using a file 
transfer package called POLY XFR. 

All VAX appl-'.cations, including the SAS package, spooler, batch "day" and 
"night" processing queues and the RMS database system ran under the 
VAX/VMS operating system which was specially configured for the VAX 11/725 
Dy a team composed of members of SIERRA Limited, Digital Equipment of 
Canada and the Edmonton Public Schools District. 

All reports were printed through the system spooler on 3 printer queues. 
Large reportc were printed at night using a low priority printer queue. 
Similarly, scheduling and calculation batch processes were run in a low 
priority "night" baton queue with minimal degradation to online, 
interactive work (editing of scheduling data was correctly locked out). 

At all times, the coraputer system performed well and provid2d g^od virtual 
machine, multiuser facllitie-^. Backups of a] 1 database files were made 
at bi-weekly intervals o 

^•2.3 Evaluation Rfjsults and Observation^^ 

The following tables indicate the result.; of testing the SAS oackage 
against the detailed evaluation criteria. The planned developments of the 
package were not allowed for in the scores. 
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78 



EVALUATION 
FkCTOR 



CRITERIA ITEMS 



PRODUCT 
SUOPE & 
FUNCTION 



7;i 
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SCBOOL RECORDS 
Pre~Reglstratlon/Enrollment 
Create student record 

- school student I.D. 

- last name 

- middle name 

- first name 

- birthdate 

- current grade 

- sex 

- feeder school 

- home address 

Registration confirmation notice 
Feeder school confinnation notice 

TOTAL Pre-Reglstratlon/Earoll«ent 
Detailed Data Items 

Student information 

- school student I.D, 

- District student I.D, 

- Alberta Education student I.D, 

- last name 

- middle name 

- flrsc name 

- birthdate 

- current grade 

- sex 

- feeder school 

- home address 

- telephone number 



WEIGHT 
(W) 



15 



(S) 


(W X S) 


10 


150 



3 


0 


2 


0 


20 


10/30 


25 


8 



MAX WT SCORE 



150 



200 



200 



Vnr SCORE/MAX WT SCORE 



.75 



81 



EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGH r 


SCORE 


WEIGHTP3 SCORE 

(U Y C\ 
VW A b) 


MA\ WT SCT)RE 


WT SCORE/hA.^ WT SCORE 


1 

-J 


- emergency c-^ntact 

- name 

- telep(^(«e 

- entry information 

- entry r^ate 

- registration code 

- vdthorawal code 

- previous schools (2) 

- homeroom int^truction 

- counsellor 

- parent /guardian information ( ip to A) 

- npve 

- ^.ddress 

- telephone (home and business) 

- teL .^hlp 

- occ /«ti'.>>n 

- locker irforjiation 

- number 

- combination 

- student indebtedness 

- religious denomination 

- program type 

- nunter of credits earned 

thi i school 

- other schools 

- acade )ic history 

- travel information 

- method 

- disv nee 

bus p*:ss infocnation 

- parking information 

- driver's licence 

- licence plate 

- parking space 

" nedlcal information 

• disabilities/behaviours 

- medications 

- allergies 


1 

[ 










81 
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EVALUATION 
FACTOR 



ERIC 



CRITERIA ITEMS 



- date of last medical 

- physician informatiDn 

- health care nund)er 
departure inforoation 

- date 

- reason 

minioiini of 6 user defined fields 



Instructor Information 

- Instructor code 

- name 

- address 

- telephone 

- social insurance number 

- language of instruction 

- certificate number 

- courses t- aught 

- minimum of 6 user Jefint'l fields 
Course Information 

- course code (5 charactei a'.pha-numeric) 

- description 

- pre-and co-requisi.:*: - (lu* .imuni of 4) 

- roust handle"f»nd*7".>r"sit jatlon 
course type 

- language of instruction 

- course accreditatior 

- credit value (? '^gits) 



wEiGirr 
(w) 



SCORE 
(S) 



Xe 



IGHTED SCOR^ 
(W X S) 



MAX Vr SCORE 
' W X S ) 







- £rade 


83 




TGTCAL Detail«2d Deta 







45 



?A/30 



WT SCORE/MAX WT SCORE 



350 



450 



.77 



84 



1 

1 EVALUATION 
1 FACTOR 

1 


CRITERIA ITEMS 


WEIGOT 
(w; 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX WT SCORE 


vrr SCORE/MAX wr score 




Repor ts/ Ir.quir ies 


25 


9 










All reports and inquiries should be avail- 
able for ail or a specified range of 
records, in various sort orders • 














- class lists 

- homeroom lists 

- student name labels 

- student address labels 
" parent address labelr 

- student I.D. cards 

- student data (alphabetical or numerical 
order) 

- parent data (alphabetic al or nuiTierical 
order) 

- instructor data (alphabetical or numer- 
ical order) 

- course data 

- student phone list 

- student name list 

- student grade list 

- feeder school list 

" locker information list 

- student population by Instruction r.ype 

- fee sheets 














The system 3hould allow production jf 
available data. 














TDTCAL Reports/Inquiries 


25 


9 


225 


250 


.9 




total school records 


90 


A3/70 


725 


900 


Ol 


85 
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EVALUATION 
FACTOR 


CRITERIA IfEMG 


WEIGHT 
(W) 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX Wr SCORE 


wr SCORE/MAX vrr score 




SCHEDULING 














Detailed Data Itens 














Course code 
- Course section 














Manual scheduling (Arena Scheduling) 


7 


10 


70 








Pre-scr -gj! Ing 














Course inquests 














manual entry 


5 


10 


50 








automated entry 


9 


0 


0 








- allow studenc to specify mandatory/ 
compulsory courses , 

- preferred courses, preferred 
alternatives, etc. 

*" allow student to specify preferred 
section, semester, or Instructor 














Edit and validation of course requests 


7 


5 


35 








- checking ol pre- and co-requisites i 
the curre^u students' requests as well 
as history files 

- capability to override pre- and co- 
requisites 

- capability to complete pre-requlslte 
checking for students from other 
District schools. 

Pre-schedullng reports 


9 


7 


63 






87 

r ■ — ' 


- potential conflict matrix — for all 
or a specified range of courses. 
/uiui.Li.untf 1 selection criteria may oe 










1 



EVALUATIC»I 
FACTOR 



CRITERIA ITEMS 
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based on the number of requests or the 
number of sections. 

- course tally 

- students wi 'i no requests 

- stiJent course request list 

- min/max request list 

- min/max credit lisi: 

- v^irification tickets 

- arena scheduling labels 

- students missirg compulsory courses 

- students requesting specific course or 
group of courses 

Master schedule builder 



Capability to build a master schedule 

manually 

automatically 
Capability of handling a variety of 
Scheduling units 

- full ypar 

- semester 

- trimester 

- quartermester 

- 6 week unit 

~ any combination of the above 

User defined timetable rotation/tumble 
Flexible number of periods per day 
Capability to specify exclusive male or 
female sections 

Qjpabriity to maintain current and future 
year/ jemester master schedules 













WEIGHT 
(W) 


SCGI^ 
(S) 


UEIGHTEO SCX)RE 
(W X S) 


MAX Vrr SCX)RE 


WT SCORE/MAX WT SCORE 




8 


43 






9 


0 


0 






9 


6 


5A 






:o 


5 


50 






10 


3 


30 






5 


9 


45 






8 


6 


48 
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EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX VT SCORE 


VT SCORE/M/»JC WT SCORE 




Scheduling Process 














User defined scheduling sequence 


6 


9 










- low grades first 

- high grades first 

- A to Z 

- Z to A 

Unscheduling of no-shows/vdthdrawals 


5 


i 


15 








Scheduling of individual student or small 
groups of students 


6 


9 


5U 








Capability to reset all students or 
partially sciieduled students 


8 


5 


AO 








Capability to lock scheduling assignments 
for all students or a group of students 


8 


0 


0 








Restart ciipability 


8 


5 


^0 








Course weighting/semester balancing 
(ensure even course load for students) 


8 


10 


80 








Blocking; of courses 




7 


A9 








Section balancing 


8 


9 


72 








Class balancing (males-females) 


«♦ 


' 


?8 








Capability to keep scheduling open after 
school start while starting to use the 
attendance nt>du3e 


9 


9 


81 








Scheduling Reports/Inquiries 


10 


8__ 


80 
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- student timetables — grid and list 
format 

- iiiacructor timetables — grid and list 
furmaC 

- room tiuetables — grid and list format 

- master schedule 

- student scheduling conflict.: 

- students partially scheduled 
^ unassigned time 
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EVALUATION 
FACTOR 


CRITERIA ITE>1S 

i 


WEICHT 
(W) 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX WT SCORE 


WT SCORE/MAX WT fXORE 




Junior High Scheduling Requirements 














Homeroom grouping for core subjects 


0 


0 


0 






1 


Capability of scheduling any course in 
any combination and number of time 
periods 


0 


0 


0 








TOTAL soieduldk; 


181 


160 


1086 


1810 


.6 




STUDENT ATTEKDANCE 














Entry of Attendance Data 














manual entry 


3 


7 


35 








dP.tomated entry 


9 


0 


0 








Mujtiple user-defined a'osonce types 


8 


9 


72 








Capability to record attendance data at 
various intervals 


10 


8 


60 








- daily 

- twice per day 
perioa Dy penoo 

- subject by subject 














Attendance history 


8 


7 


56 








~ at least ten days detail 
- cunnulative totals 














Attendance reports/inquiries 


10 


8 


80 
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- student by class 

- student by subject 

- student by period 
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EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


SCORE 
(S^ 


WSIGliTED SCORE 
(W X S) 


MAX Vrr SCORE 


WT SCORE/MAX WT SCORE 




- homeroom attendance 

- daily summary 

- weekly sunmary 

- monthly suraroary 
~ multiple absence 

- capability to produce unexcused 
absence report for the current day 
within 30 minutes 

- the system should allow user defined 
reports/inquiries using available data 














TOTAL ATIQffiANCE 


50 


37/60 


:o3 


500 


.61 




CTUDEWr MARKS 














Entry of marks data 














manual 


3 


7 


35 








automated 


9 


0 


0 








Marks data 


10 




70 








~ mlniimim o 4 term marks plus fii.al mark 
- letter or percentage grades 














Student Exams 


6 




24 








Exam timetable builder 














- automated 

- manual 












) 


Exam Reports/ Inquiries 

- potential exam conflict matrix 

- exam schedules 










>j u 



EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX m SCORE 


Wr SCORE/MAX Wr SCORE 




Reports/Inquiries 


iq_ 


6 


60 










proof list 
report cards 

- marks data 

- final mark, calculated according to 
user^efined formula attenandance data 

" class averages 

- honour lists 

- potential failure lists 

- graduation list 
















TOTAL STTJDENT HARKS 


40 


24/50 


189 


400 


.47 






UTTLITY FDNCTiaiS 
















Backup/Restore 


12 


5 


60 










Security/ Controls 


8 


8 


64 










TOTAL UTILm FDNCTIONS 


20 


13/20 


124 


200 


.62 
























GRAND TOTAL » PRODUCT SCOPE 






267/440 




2427 




3810 




.64 






AND FUNCTION 














EASE OF 


- flexibility 


60 


7 


420 








USE 


- modular, table driven 

- help facilities 
~ menu driven 
















GRAND TOTAL, EASE OF OSB 


1^ 60 




' 1 


1 


*20| 


1 




600 




.7 




1 
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00 



EVALUATION 


CRITERIA ITEMS 


WEIGHT 


SCORE 


FACTOR 






(S) 






ftn 
ou 


Q 

O 


GDNSIIlERATinM^ 


byaLcui soiLware envikOnmenL 








~ operating system 








ulix 1 Lies 








~ d J tdbase mana^enicn t / sys tem 








inLcl. llaXS/ Liies 








~ netwrking capabili ties 








- user hcx)ks 








- modularity of the system 








GRAND TOTAL, TECHNICAL CONSIDERATIONS 


80 




I 

i » 


SIPPQRT & 


XULox VcLoUo Wittrrtf/ iHJw Lai 


70 


7 


SEKVTCRS 


l^acivcigc buppui. t uiia services 








- software support, custom 








modifications 








□ocumenLoL ion 








user guiae , appxicaLiou system, 








procedural, operations guide. 








file layouts 








1. id 1 rung 








- applications system, operation; I 








(DP), availability schedule, format, 








location, prerequisites 








impjLcinunLa c ion 








~ I. raining 








ini L la i izoLion v,conversion,tiie set" 








tin r»i»t"r«it" €r% r*Tni3 ^ 








- implemeitation plan 
















GRAND TOTAL, SUPPORT & SERVICES 


1 
1 




7 











WEIGHTED SCORE 
(W X S) 



6A0 



MAX SCORE 



WT SCORE/MAX WT SCORE 



640 



800 



.8 



490 



490 



700 



EVALUATION 
FACTOR 



CRITERIA ITt^lS 



PROnXT 
qUALIFICAnOKS 



- package background 

- reliability 

- current development status 

- number of installations 

- product development plans 

- release concept, portrbility, 
verticali tv 



CRAHD TOTAL, PRODUCT QUAJ.IPICATIOMS 



ERIC 



- Corporate information 

- background and history 

- financial performance 

- employee base 

- Market volatility and vendor stability 

- References 

- Contractual Terms 

- maintenance 

- warranty 

- ownership rights 

- discount structure/price limit 



GRAND TOTAL, VENDOR 



wEicm 

(W) 



80 



So 



70 



70 



SCORE 
(S) 



WEIGHTED SCORE 
(W X S) 



320 



320 



350 



350 



MAX Wr JCORE 

(W X S ) 
max' 



800 



UT SCORE/MAX WT SCORE 



700 



.4 



.5 
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Observations 



For each of the six major evaluation factors, the following comments and 
observations are offered in support of the quantitative evaluation of SAS. 

(A) Product Scope and Function 



School Records: Comprehensive data fields, validation and edit 

checking are marred only by the absence of some 
key data fields and a clumsy, although usable, 
method of providing user-defined fields • Course 
information was adequate but lacked essential 
edit/detail reports • 

Scneduling: The scheduler is powerful-, flexible and 

parameter-driven allowing the user several passes 
with relaxation of certain requirements (such as 
class balancing) in the later passes. Editing 
and validation of course requests was v^eak and 
there was a A ack of flexibility in the area of 
definition of rotation/ tumble and nt .er of 
periods per day. VHien the scheduled classes were 
loaded we had to "patch" the system tables to go 
back to the scheduling pro'^ess. 

Attendance and Marks: These functions were tested in outline, i#e. full 

production data was ^ot used. Both modules are 
acceptable with fast data entry of attendance and 
marks data, fast and accurate reports. Student 
examination data capture and repoiling is v^ry 
weak and the absence of automated f acili tie^ f c r 
the capture of attendance data is considered to 
be a very weak point. 

Utility Functions: Security controls are reasonable and well 

structured. There are 3 levels of security: 
System Manager (mainly external to the 
application package), Us^r Manager, and User. 

Database backup and restore functions are handled 
by the Operating System and are adequate but 
slow. Also, they require the application package 
to be stopped. 

Overall, the product is well designed with good 
interactive screens and messages and provides all 
of the main school information functions required 
in a true i^ulti-user environment. 
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Ease of Use The system is, in general, user friendly with a 

"long hand" method of reaching each function and 
an experienced user's "shorthand" method. The 
package is reasonably flexible and modular 
although the job control language files tend to 
be inflexible in some function areas. The system 
is largely menu driven with some "hidden" menu 
ite'iis reserved for the User Manager. 

On the negative side, there were times when VAX 
BASIC or VAX/VMS messages were displayed on the 
screen and programs did occasionally crash, also 
displaying system messages. Help facilities 
were at times cryptic and one needed to study the 
detailed documentation to perform certain 
functions. 

(C) Technical Consid'^rctions 

The greatest advantage of thc: VAX computer is the 
powerful operating system and utility software. 
VAX/VMS is a true multi--user virtual machine 
operating system and handles 8 users on the small 
VAX 11/725 computer. The SAS package benefits 
from the sophisticated operating system and 
spooler facilities using multiple parallel tasks 
to increase throughput. The system is not 
networked (as a local are-i network) but this 
feature is not needed. There are powerful 
communications facilities available, both 
synchronous and asynchronous with IBM 3270 
protocols, although these facilities were aot 
tisted during this project. 

The datab;^se management system (DBMS), RMS, is a 
powertul indexed sequential system. Distributed 
Systems Team used the DBMS extensively for data 
loading and field by field editing. 

The application package provides good user hooks 
in the job control streams and database files and 
is modular in design. 

(D) Support and Services 

Technical and user support was prompt and 
acceptable. The company is located in Vancouver 
so that there are weaknesses In the ability to 
obtain on-site or detailed support. We received 
some custom modifications and "patches" during 
the course of the evaluation. 
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Documentation is very comprehensive and weJl laid 
out with a * toad map" at the front and step-by- 
stop guides for each of the main processes . The 
technical guide, called the Central Users Guide, 
is of poorer quality but does document some of 
the "hidden" screens « 

A training course was provided at the beginning 
of the study and there was some follow-up from 
the instructor at roughly monthly intervals. The 
implementation plan was designed by the 
Distributed Systems Team and executed with only 
minor modifications. 

(E) Product Qualifications 

The SAS package was developed initially as a 
centralized time-sharing system for school 
district use. This aspect of the package is 
still relevant and it could be used for groups of 
schools. We were unable to obtain references 
from other production sites, mainly due to the 
fact that thfc product is relatively new. The 
package is, however, in a stable state and shows 
a high degree of reliability. 

Some developments are being made, mostly in tho 
area of system tools for application 
programmers. Releases are fairly infrequent with 
only one major upgrade made during the four month 
evaluation period and none in the five months 
since. 

(F) Vendor The Vendor is a fairly stable software company 

based in Vancouver. It is strongly involved in 
the area of school information software 
development but seems to be light in the area of 
production systems . 

The contractu-^l terms and warranty of the product 
are reasonable but still seem to be geared more 
towards centralized control )ather than local 
school operations . 
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4 . 2 • 4 System Performance, Strengths and Weaknesses 
Key Performance Indicators 
School Test Site Parameter 



Jasper Place CHS 



Scheduler - Time 
Scheduler - Performance 
Scheduler - Expected Perf« 



SAS 

Result 
6:20 hours 
90% 

95% 



Student Timetables 
Attendance Register 
School Directory 
Marks Regis tier 
Attendance Reports 
Class Lists 
Conflic- Matrix 
Course Request Tally 



1:00 hours 
0:30 hour 
1:20 hour 
0:20 hour 
2:30 hours 
2:00 hours 
0:22 nour 
0:38 hour 



Jasper Place CHS 



1846 students 



(All timings are in hours :minutes) 



ERIC 



(63) 106 



System Stringr hs 



Multi-user : 

Data transfer 
from mainframe: 



User friendly: 

Good documentation: 

System Weaknesses 
Course credits: 

Scheduler complexity : 



School stati. 
parameters complexity: 



Reoorts : 



this feature is important for devplopment and 
production use. 



data was loaded from mainframe , Series; 1 
minicomputer, IBM microcomput iv and DJilC RAINBOW 
microcomputer • In all cases, loading and file 
transfer was straightforward and error-free. 

with a couple of exceptions, the screen layouts 
and method ptration were user friendly* 

very detailed with plenty of examples snd 
guidesheets showing the sequence of operations. 



The SIERRA package would only allow up to 9.99 
credits for a course - some grade il and 12 
course can earn up to 30 credits. 

the tuning parameters and other data required, 
such as pass control, were overly complex and 
difficult in some cases to set up correctly on 
the first few runs. 

several hundred screens of static data, such as 
coin's for absence, were required. Again, there 
was too much data complexity and a dis- 
proportionate amount of work i*"volved in setting 
I hem up. 

some reports did not work at all, some gave 
strange or incomplete results , some worked but 
could not be printed out. The must difficult 
problem was the absence of some key reports such 
as listings of the st::«-ic parameters and key data 
files. Overall, the reporting subsystem is 
foirly weak and on a few occasions, the systems 
analyst had tr> define and develop reports under 
the Report Writer program which is not user- 
friendly. 
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Spec.fic System Problems 



"Students scheduled 
with free time": 



does not produce anything except a BASIC run-time 
error* 



B105 Batch loader: 



R107 Student Schedule: 



once this is run to load scheduled students into 
classes it is very difficult to go back and re- 
run the Batch Scheduler, v/e had to patch the 
database considerably. 



it this report is run with the "save" ootion, 
is impossible to delete the report file. 



it 
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5.0 COMPARATIVE EVALUATION OF SIMS - SENIOR HIGH SCHOOL PERSPECTIVE 



A detailed comparison was made of the two minicomputer approaches tested 
at the Senior High School level. The reader is reminded that three 
microcomputer based products were also tested in similar environments and 
are the subject of another report . 

5.1 Comparison Summary and Review ot SIMS Evaluation Data 

The following tables show the quantitative evaluation data for the two 
minicomputer based school information management systems whicr ware 
evaluated. This data is displayed on the Comparison Summary and Review 
form which was referred to previously. This form parallels the Detailed 
Evaluation Criteria forms. The Detailed Scoring Comparison Form differs 
from the Detailed Criteria forms in that all (non-scorable) context 
related criteria are omitted and only the weighting factor, raw and 
weighted scores fron the evaluation are displayed. Various levels of 
totals are shown on the form to facilitate the quick and objective 
comparison of systeiu performance. 
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EVALUATION 
FACTOR 



CRITERIA ITEMS 



FRODOCT 
SCOPE 4 
FUkCTIOW 



ERLC 



SCHOOL RECORDS 

Pre-ReglBtratlon/EnroI Iment 
Create student record 

Registration confirmation notice 
Feeder school confirmation notice 

TOTAL Pre-Registration/Enrollaent 

Detailed Data Itema 

Student InforrTation 

Instructor Information 

Course information 

TOTAL Detailed Data Iteu 
Reports/Inquiries 
TOTAL Kafwrta/Inqoiries 
TOTAL SCHOOL RECORDS 
SCKEDULING 

Manual scheduling (Arena Scheduling) 



no 



WEIGHT 
(W) 



15 



20 



25 



15 



45 



25 
25 



90 



SAS 

SCOPE WEIGHTED 
SCORE 
(S) (W X S) 



10 

0 
0 

10/30 

8_ 

9 
7 

24/30 
9 

9/10 
43/70 



150 



150 



200 



45 



105 



350 



225 
225 



725 



PASS 

CnfTSKD STSTBN 

SCORE WEIGHTED 
SCORE 

(S) (W X S) 



13/30 



_3 

__6 

7/30 

8 

8/10 
38/70 



135 



200 



15 



90 



305 



200 
200 



649 



10 



70 



49 



Ui 



EVALUATION 


CRITERIA ITEMS 


WEIGHT 
(W) 


SAS 

(S) 


SCORE 
(W X S) 


PASS 
CKNTRED SYSTEM 

SCORE 

(S) (W X S) 




Pre-8cheduling 
Course Requests 
















manual entry 


5 


10 


50 


Q 
0 


AO 






automated entry 


9 


0 


0 


3 


27 






Edit and validation of course requests 


7 


5 


35 


4 


28 






Pre-schedullng reports 


9 


7 


63 


7 


63 






TOTAL Prc~S chedul i ng 


30 


22/40 


148 


22/40 


158 






Master schedule builder 
















Capability to build a master scheduler 
manually 


6 


8 


A8 


7 


A2 






automatically 


9 


0 


0 


0 


0 






Capability of handling a variety of 
scheduling units 


9 


6 


5A 


3 


27 






User defined timetable rotation/tumble 


10 


5 


50 


J 


30 






Flexible number oL periods per day 


10 


3 


30 


8 


80 






Capability to specify exclusive -^ale or 
female sections 


5 


9 


A5 


8 


40 






Capability to maintain current and future 
y^ar/semester master schedules 


8 


6 


AS 


8 


64 






TOTAL Kastcr Schedule Builder 


57 


37/70 


275 


37/70 


283 






Scheduling Process 
















User defined scheduling sequence 


6 


9 


5A 


9 


54 






Unscheduling of no~shows/%rlthdrdwal8 


5 


3 


15 


9 


45 


ii:: 















EVALUATION 
FACTOR 



CRITERIA ITEMS 



Scheduling of individual student or small 

groups of students 

Capability to reset all students or 

partially scheduled students 

Capability to lock scheduling assignments 

for all students or a group of students 

Restart capability 

Course weighting/semester balancing (ensure 
even course load for students) 
Blocking of courses 
Section balancing 
Class balancing (males-females) 
Capability to keep scheduling open after 
school start while starting to use the 
attendance module 

TOTAL Scheduling Process 

Scheduling Reports/Inquiries 



Junior High Scheduling Requirements 

Homeroom grouping for core subjects 
Capability of scheduling any coi-rse in nny 
combination and number of time periods 

TOTAL SGHEDULING 



STUDEJrr ATTENDANCE 



Entry of Attendance Data 



114 



manual entry 
automated entry 
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weigh: 

(W) 



5A5 

SCORE WEIGHTED 
SCOR': 
(S) (W X s) 



54 



PASS 
CENTRED SYSTEM 

SCORE WEIGHTED 
SCORE 

(S) (W X S) 



36 



40 



40 



16 



10 



80 
49 
72 
28 



64 
28 
64 
32 



77 



73/110 



81 
513 



52/110 



36 
375 



10 



80 



80 



181 



150/240 



1086 



126/240 



945 



35 



40 



1 

EVALUATION 
FACTOR 


1 — 

CRITERIA ITbMS 


1 

WEIGHl 
(W) 


SCORE 
(S) 


SAS 

WEIGHTED 
SCORE 
(W X ^) 


PASS 
CENTRED SYSTEM 

SCORE WEIGHTED 
SCORE 

(S) (W X S) 




Multiple user-defined absence types 


8 


9 


72 


8 


64 




Capability to record attendance data at 
various intervals 


10 


6 


60 


o 






Attendance history 


8 


7 


56 


8 


64 




Attendance reports/inquiries 


10 


8 


80 


8 


80 




TOTAL ATTENDANCE 


50 


37/60 


303 


40/60 


328 




STUDENT MARKS 














Entry of mark i data 














manual 


5 


7 


35 


0 


0 




autcmated 


9 


0 


0 


0 


0 




Marks daua 


10 


/ 


Jb 


0 


0 




Student Exams 


6 


4 


24 


0 


0 




ET^m timetable Guilder 
Exam Reports/Inquiries 














Reports/inquiries 


10 


6 


60 








TOTAL STODKNT MARKS 


40 


24/50 


189 


0/50 


0 













lio 



U7% 
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EVALUATION 
FACTOR 



CRITERIA ITEMS 



OTILITY FUNCTIONS 

liackup/Restore 
Security /Controls 
TOTAL OTILITT FTNCTIOIfS 



GRAND TOTAL, PRODUCT SCOPE AND FUNCTION 



EASE OF 
USE 



GRAND TOTAL, EASE OF USE 



TECHNICAL 
CONSIDEIATION 



GRAND TOTAL I TICNNIGAL C0N81DIKXTI0N8 



SUPPORT 4 
SERVICES 



GRAUD TOTAL, SUPPORT & SERVICES 




SAS 

SCORE WEIGHTED 
SCORE 
(S) (W X S) 



13/20 




7/10 



8/10 



7/10 



60 



64 



124 



267/4A0 




2427 j 


7 


420 







420 



640 



1 



490 



490 



PASS 
CEN^iRED STfTEM 

SCORE V/EIGHTED 
SCORE 
(S) (W X S) 



8/20 



212/440 



5/;o 



5/10 



72 



16 



88 



201J 



300 



300 



320 



tl3 [ ! 



3W 



119 



EVALUATION 
FACTOR 



CRITERIA ITEMS 



FROIHJCT 
QaALIFICATIONS 



VKHDOR 



12U 



CRAHD TOTAL, PRODOCT QOALIFICATIORS 



CKAHD TOTAL, VEHDOR 
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SCORE 



SAS 

WEIGHTED 
SCORE 
(S) (W X S) 



320 



4/10 



5/10 



320 



350 



350 



PASS 
CENTRED SYSTEM 

SCORE WEIGHTED 
SCORE 

(S) (W X S) 



560 



7/10 



i 8/10 



560 



560 



560 



5.2 Relative Suitability of SIMS to the Senior High Schools 

The foregoing results, can now be used to determine the relative 
suitability of the two approaches to a particular user's needs. 

The following describes a method of determining this suitability relative 
to the six major evaluation factors. 

Before determining the overall suitability of a system to the needs of 
the user, however, the user must first define the relative emphasis that 
h' wishes to place evaluation ^actors. 

The following table shows the emphasis which the evaluation team believes 
should be placed on the major evaluation factors. The emphases are 
expressed as percentages and total to 100. While it can be clearly seen 
that product scope and function is the single most important evaluat-^on 
factor, this importance is outweighted by the collective emphasis on the 
five factors. 



r. VALUATION FACTOR 


EMPHASIS (%) 


PRODUCT SCOPE AND FUNCTION 


45 


EASE OF USE (OF PRODUCT) 


10 


TECHNICAL CONSIDERATIONS 


10 


SUPPORT AND SERVICES 


15 


PRODUCT QUALIFICATIONS 


10 


VENDOR 


10 



Relative suitability .an be defined as a function of weighted score (or 
measure of product performance) and relative emphasis in the following 
way. 



Relative Suitability = (Z Emphasis) x ( weighted score) 

(max. possible weighted score) 



The ratios of weighted score to maximum possible weighted score for the 
systems evaluited are shown on the Detailed Evaluation Criteria forms 
(sections A. 1.3 and 4.2.3). 

Applying the above formula to the evaluation data at hand gives the 
following result. 




EVALUATION FACTOR 


EMPHASIS 
(%) 


RELATIVE PRODUCT SUITABILITY 






PASS 
CENTRED SYSTEM 


SAS 


PRODUCT SCOPE AND FUNCTION 


45 


23 


28 


EASE OF USE (OF PRODUCT) 


10 


3 


7 


TECHNICAL CONSIDERATIONS 


10 


4 


8 


SUPPORT AND SERVICES 


15 


7 


10 


PRODUCT QUALIFICATIONS 


10 


7 


4 


VENDOR 


10 


8 


5 


TOTALS 


100 


54 


62 



By using this process, entries in the columns identified by product names 
w/.ll be numbers less than or equal to the percent emphasis number. These 
numbers can in fact be considered as scores out, of the assigned percent 
emphasis numbers. Vertical totals of suitability for each product will 
be numbers less than or equal to 100 which can easily be compared across 
alternatives. 

The above table shows, for example, that SAS is considered to be less 
suitable than the PASS Centred System to the needs as defined in the area 
of Product Qualifications. The product scored 4 of a possible ten points 
whilst by contrast, the PASS centred system scored / of a maximum 
possible 10 points for the same evaluation factor. 

Suitabilities calculated according to the method described should be 
viewed as relative measures of the extent to which a product meets a 
particular user's needs. This suitability will vary according to the 
completeness of the criteria, user defined weighting factors, percent 
emphasis and, very obvious /, on the scores assigned by the product 
evaluator. Within this context, therefore, it is very important to note 
that the evaluation process which has been developed and applied in this 
way is extremely flexible allowinj^ the user complete discretion to decide 
which criteria will be used, the weighting factors and the percent 
emphases. In short, all that a user of this process needs to depend on 
are the actual raw scores which were assigned as a result of the hands on 
testing work. 

To illustrate the flexibility of the process, two more examples of 
product suitability are shown below. The reader will see that the 
percent emphasis dis tribution has been changed (while still totalling 
100) in eacl case. In these examples, the individual criteria weighting 
factors were not changed (though they could have been) and thus the same 
ratios of weighted score to maximum weighted score were applied. 
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SIMULATION 1 (SENIOR HIGH SCHOOL PERSPECTIVE) 





(%) 




'^lirT\RTl T TV 






PASS 
CENTRED SYSTEM 


c; /\c 


PRODUCT SCOPE AND FUNCTION 


55 


29 


35 


EASE OF USE 


20 


10 


14 


TECHNICAL CONSIDERATIONS 


5 


2 


4 


SUPPORT AND SERVICES 


10 


5 


7 


PRODUCT QUALIFICATIONS 


5 


3 


2 


VENDOR 


5 


4 


2 


TOTALS 


100 


53 


64 



SIMULATION 2 (SENIOR HIGH SCHOOL PERSPECTIVE) 



EVALUATION FACTOR 


EMPHASIS 
(%) 


RELATIVE PRODUCT 


SUITABILITY 






PASS 
CENTRED SYSTEM 


SAS 


PRODUCT SCOPE AND FUNCTION 


50 


26 


31 


EASE OF USE 


20 


10 


14 


TECHNICAL CONSIDERATIONS 


10 


4 


8 


SUPPORT AND SERVICES 








PRODUCT QUALIFICATIONS 


20 


14 


8 


VENDOR 








lOT/LS 


100 


54 


61 
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6,0 PRODUCT EVALUATIONS - JUNIOR HIGH PERSPECTIVE 



While the two minicomputer systems were not physically tested in a junior 
high school environment > one of the two systems - bAS - was evaluated 
against the specific Junior High school criteria. 

6,1 Evaluation Results and Observations 

The following r^ibles show the outcome of the quantitative evaluation of 
SAS against tie detailed evaluation criteria from the junior high school 
perspective. 
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EVALUATION 
FACTOR 



CRITERIA ITEMS 



PRODUCT 
SOOPE & 
FUNCTION 



126 
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SCHOOL RECORDS 

?re-Reglstrat Ion/Enrollment 
Create student record 

- school student I.D. 

- last name 

- middle name 

- first name 

- birthdate 

- current grade 

- sex 

- feeder school 

- home address 

Registration confirmation notice 
Feeder school confirmation notice 

TOTAL Pre-4(egi8tratlon/Earollmt 
Detailed Data I terns 

Student Information 

- school student I.D, 

- District student I.D. 

- Alberta Education student I.D. 

- last name 

- middle name 

- first name 

- birthdare 

- current grade 

- sex 

- feeder school 

- home address 

- telephone number 



WEIGHT 
(W) 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX VT SCORE 


W SCORE/MAX WT SCORE 


15 


10 


150 






3 


0 


0 






2 


0 


0 






20 


10/30 


150 


200 


.75 


25 


8 


200 
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EVALUATION 
FACTOR 



CRITERIA ITEKS 



emergency contact 

- name 

- telephone 
entry information 

- entry date 

- registration code 

- withdrawal code 
previous schools (2) 
homeroom instruction 
counsellor 

parent/guardian information (up to ^) 

- name 

- address 

- telephone (home and business) 

- relationship 

- occupation 
locker information 

- number 

- combination 
student indebtedness 
religious denomination 
program type 

number of credits earned 

- this school 

- other schools 
academic history 
travel information 

- foethod 

- distance 

- bus pass information 
parking information 

- driver's licence 

- licence plate 

- parking 9pace 
medical inft *mation 

- disabilities/behaviours 

- medications 

- allergieR 



WEIGHT 
(W) 



SCORE 
(S) 



WEIGHTED SCORE 
(W X S) 



MAX WT SCORE 



WT SCORE/Mi<^^ WT SCORE 



EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX WT SCORE 

(W X S ^ ) 
^ max' 


1 

WT SCORE/MAX WT SCORE 




- date of last medical 

- physician information 

- health care number 

- departure information 

- date 

- reason 

- minimum of 6 user defined fields 














Instructor Information 


5 


9 


45 








- instructor code 

- name 

- address 

- telephone 

- social insurance number 

- language of instruction 

- certificate number 

- courses taught 

- minimum of 6 user defined fields 














Courr^ information 


15 


7 


105 








- course code (5 character alpha-numeric) 
description 

- pre-and co-requisites (minimum of 4) 

- must handle"and"/"or"situation 

- course type 

- language of instruction 

- course accreditation 

- credit value (2 digits) 

- pass/fail mark 

- grade 














TOTAL Detailed Data I ten 


45 


24/30 


350 


450 


.77 


130 
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EVALUATION 
FACTOR 


CRITERIA ITFKS 


WEIGHT 
(W) 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX WT SCORE 


WT SCORE/KAX VTT SCORE 




Reports/Inquiries 


25 


9 


22b 








All reports and inquiries should be avail- 
able for all or a specified range of 
records, in various sort orders. 














- class lists 

- homeroom lists 

- student namt labels 

- student address labels 

- parent address labels 

- student I.D. cards 

- student data (alphabetical or numerical 
order) 

- parent data (alphabetical or numerical 
order) 

- instructor data (alphabetical or numer- 
ical order) 

- course data 

- student phone list 

- student name list 

- student grade list 

- feeder school list 

- locker information list 

- student population by instruction type 

- fee sheets 














The system should allow production of 
user-defined reports/inquiries using 
available data. 














I01AL Reports/Inquiries 


25 


9 


225 


250 


.9 


13;^ 


TOTAL SCHOOL RECORDS 


90 


43/70 


725 


900 


_ T 















EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


SCORE 

(s) 


WEIGHTED SCORE 
(W X S) 


MAX WT SCCKE 


WT SCORE/M/i:< WT SCORE 




SCHEDULUC 














Detailed Data Items 














- Course code 
Course sect.cn 














Manual scheduling (Arena Scheduling) 


7 


10 


70 








Pre-scheduling 














Course Requests 














iivinitAl pntrv 


5 


10 


50 








automated entry 


9 


0 


0 








- allow student to soecify mandatory/ 
conpulsory courses ^ 

preferred courses » prefericd 
alternatives, etc* 

- allow student to specify preferred 
section, seicester, or instructor 














Edit and validation of course requests 


7 


5 


35 








- checking of pre- and co-requisites in 
the current students' requests f^s well 
as history files 

- capability to override pre- and co- 
requisites 

- capability to complete pre-requlsite 
checking for students from other 
District firhnnlfi 

Pre-schedullng reports 


9 


7 


63 






134 


- potential conflict matrix — for all 
or a specified range of courses. 
Additional selection criteria may be 
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EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX WT SCORF 


urr snnRh /max ltt <;mBF 




based on the number of requests or tt 
number of sections. 

- course tally 

- students with no requests 

~ student course request list 

- mln/max request list 
~ min/niax credit list 

- verification tickets 

- arena scheduling labels 

- students missing compulsory courses 

- students requesting specific course or 
group of courses 


\ 






1 






Master schedule builder 














Capability to build a master schedule 
manually 


6 


8 


48 








automatically 


9 


0 


0 








Capability of handling a variety of 
cheduling units 


9 


6 


54 








- full year 

- semester 

- trimester 

- quartemester 

- 6 week unit 

- any combination of the above 














User defined timetable rotation/tumble 


10 


5 










Flexible number of periods pei day 


10 


3 






1 




Cdoability to specify exclusive male or 
female sections 


5 


9 


45 






13o 


Capability to maintain current and future 
year/semester master schedules 


8 


6 


48 




13/ 













EVALUATION 
FACTOR 



CRITERIA ITEMS 



Scheduling Process 

User defined scheduling sequence 

- low grades first 

- high grades first 

- A to Z 

- Z to A 

Unschedullng of no-shows/wlthdrawals 

Scheduling of Individual student or small 

groups of students 

Capability to reset all students or 

partially scheduled students 

Capability to lock scheduling assignments 

for all students or a group of students 

Restart capability 

Course weighting/semester balancing 

(ensure even course load for students) 

Blocking of courses 

Section balancing 

Class balancing (males-females) 

Capability to keep scheduling open after 

school start while starting to use the 

attendance module 

Scheduling Reports/Inquiries 

- student timetables — grid and list 
format 

- instructor timetables — grid and list 
fornat 

- room timetables — grid and list format 

- master schedule 

- student scheduling conflicts 

- students partially scheduled 

- unasslgned time 
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wEiCfrr 
(w) 


SCORE 
(S) 


WKICHTEU SCORf: 
(W X S) 


MAX Wr SCORK 


w SCOP'S/MAX wr Sa)KK 




6 


9 


5A 




1 


5 


3 


15 


6 


9 


5A 


8 


5 


AO 


8 


0 


0 


8 


5 


AO 


8 


10 


80 


7 


7 


A9 


8 


9 


72 


A 


7 


28 


9 


9 


81 


10 


8 


80 
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EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX WT SCQFE 


WT SCORL/MAX WT SCORE 




Junior High Scheduling Requirements 














Homerooiji grouping for core subjects 


9 


5 










Capability of scheduling any course In 
any combination and number of time 
periods 


10 


5 


50 








TOTTAL SaiEDULlNG 


200 


160 


1181 


2000 


.63 




STUDEOT ATTENDAI^ 














Entry of Attendance Data 














manual entry 


5 


7 


35 








automated entry 


9 


0 


0 








Multiple user-defined absence types 


8 


_ 9 


72 








Capability to record attendance data at 
various intervals 


10 


6 


60 








- daily 

- tvdce per day 

- period by period 

- subject by subject 














Attendance history 


8 


7 


56 








- cunmulative totals 














Attendance reports/^^quirles 


10 


8 


80 
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- student by class 

- student by subject 

- student by period 
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EVAI.UATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


SCORE 
(S) 


WEIGHTED SCORE 
(W X S) 


MAX Wr SCORE 
max' 


WT SCORE/MAX WT SCORE 




- homeroom attendance 

- daily summary 

- weekly sumnary 

- monthxy summary 

- multiple absence 

- capability to produce unexcused 
absence report for the current day 
within 30 minutes 

- the system should allow user defined 
leporLs/ inquiries using available data 






1 
1 








TOTAL ATTENDANCE 


50 


37/60 


303 


500 


.61 


















CiUtry oi marKs aaca 














manual 


5 


7 


35 








automated 


9 


0 


0 








Marks data 


10 


7 


70 








• minimum of A term marks plus final mark 
xcLLCL ui \MzLL.xziiLavxz graoes 














Student Exams 


6 




2A 








£«xam LiineLaDie Duiiaer 














- automated 
~ manual 














Exam ReTX)r ts/ Tnaul r i pk 
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- potential exam conflict matrix 

- exam schedules 
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EVALUATION 
FACTOR 



CRITERIA ITEMS 



WEIGHT 
(W) 



SCORE 
(S) 



WEIGHTED SCORE 
(W X S) 



MAX WT SCORE 



WT SCORE/MAX WT SCORE 



EASE OF 
USE 



144 
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Reports/Inquiries 

proof list 
report cards 

- marks data 

- final mark, calculated according to 
user-defined formula attenandance data 

- class averages 

- honour lists 

- potential failure lists 

- graduation list 

TOTAL SrrUDEWr MARKS 



DTiLrnr fdmctions 

Backup/Restore 
Secur 1 ty/ Controls 
TOTAL UTILm FUNCTIONS 



GRAND TOTAL, PRODUCT SCOPE 
AND FUNCTION 

- flexibility 

- modular, table driven 

- help facilities 

- menu driven 



GRAND TOTAL, EASE OF USE 



10 



40 



12 



20 



400 



60 



60 



24/50 



13/20 



277/4601 



60 



189 



4O0 



.47 



60 



64 



124 



200 



.62 



2522 



4000 



.6305 



A20 



420 



600 



Ho 



00 
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EVALUATION 
FACTOR 



TECHKICAL 
OONSIDERATIOHS 



SUFFOirr h 
SERVICES 



146 



CRITERIA ITEMS 



hardware 

system software environment 

- operating system 

- utilities 

- database management/system 
internals/files 

- networking capabilities 

- user hooks 

- modularity of the system 



;RAND total » TECHNICAL CONSIDERATIONS 



local versus where/how far 
package support and services 

- software support, custom 
modifications 

documentation 

- user guide, application system, 
procedural, operations guide, 
file layouts 

training 

- applications system, operational 
(DP), availability schedule, format, 
location, prerequisites 

implementation 

- training 

- initialization (conversion, file set- 
up, output forms) 

- implementation plan 



GRAND TOTAL, SUPPORT & SERVICES 



WEIGHT 
(W) 



80 



SCORE 
(S) 



WEIGHTED SCORE 
(W X S) 



80 



70 



70 



6A0 



MAX WT SCORE 
(W X 



MO 



A90 



1^800 



WT SCORE/MAX WT SCORE 



*90 



700 
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EVALUATION 
FACTOR 



CRITERIA ITF>1S 



PRODUCT 
QUALIFICATIONS 



CD 



VENDOR 



ERIC 



- package background 

- reliability 

- current development status 

- number of installations 

- product development plans 

- release concept, portability, 
verticality 



GRAND TOTAL, PRODUCT QUALIFl^ iTIONS 



WEIGfff 
(W) 



80 



80 



- Corporate information 

- backgrounc' and history 

- fi ancial performance 

- en:ployee base 

- Market volatility and vendor stabiJity 

- References 

- Contractual Terms 

- maintenance 

- warranty 

- ownership rights 

- discf it structure/price lirai^ 



GRAND TOTAL, VKNDOR 



70 



SCOPE 



WEIGHTED SCORE 
X S) 



320 



70 



MAX Wr SCORE 



320 



350 



350 



800 



700 



WT SCORE/MAX WT SCORE 



J 



.5 



6.2 Observations 



All evaluation observations, as described section 4.2*3 are equally 
appropriate for the Junior High school perspective. In pddition, the' 
following specific points were tested: 



Homeroom grouping for core 
subjects : 



Capability of Scheduling 
any course in any 
combination and number of 
:ime periods: 



A>-xxity to handle tumble/ 
rotat j on schedules: 



Adequate but indirect method of grouping 
subjects. No choice is available in the 
definition of the members of the group. 

There is reasonable flexibility within the 
SAS system but the physical timetable 
are detached from the logical meeting 
periods and it is impossible to produce 
physical (that is start tiira and day to end 
time) timetables. 

The SAS system provides a reasonably large 
number of tumble/rotation sequences and 
could comfortably handle Junior High school 
schedules. 

The results of these terts were compared with two microcomputer based 
pack Bs. The School System developed by Columbia Computing and SIRS 
developed by MIG Limited. 

^•^ Relative Suitability of SIMS to the Junior Hi^^h Schools 

The relative suitability of SIMS to the junior high schools was determined 
using the same procedure and percent emphasis distribution as was used in 
the senior high school situation (see section 5.2). The outcome of this 
procedure is shown in the table below. 



EVALUATION FACTOR 


EMPHASIS 
(%) 


RELATIVE PRODUCT SUITABILITY 
SAS 


PRODUCT SCOPE AND FUNCTION 


45 


2S 


EASE OF USE 


10 


7 


TECHNICAL CONSIDERATIONS 


10 


8 


SUPPORT AND SERVICES 


15 


10 


PRODUCT QUALIFICATIONS 


10 


4 


VENDOR 


10 


5 


TOTAL 


100 


62 
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The following two tables show alternative deterrainations Df suitability which 
parallel those provided for the senior high situation presented in section 5.2 
of this report. 



SIMULATION in (JUNIOR HIGH PERSPECTIVE) 



EVALUATION FACTOR 


EMPHASIS 
(%) 


RELATIVE i^RODUCr SUITABILITY 
SAS 








EASE OF USE 


20 


14 


TECHNICAL CONSIDERATIONS 




4 


SUPPORT AND SERVICES 


10 


7 


PRODUCT QUALIFICATIONS 


5 


2 


VENDOR 


5 


2 


j TOTAL 


100 


63 
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SIMULATION #2 (JUNIOR HIGH PERSPECTIVE) 



EVALUATION FACTOR 


EMPHASIS 
(%) 


RFI.ATTVF PROnflPT <^IITT ART I T TV 

SAS 


PRODUCT SCOPE AND FUNCTION 


50 


31 


EASE OF USE 


20 


14 


TECHNICAL CONSIDERATIONS 


10 


8 


SUPPORT AND SERVICES 






PRODUCT QUALIFICATIONS 


20 


8 


VENDOR 






TOTAL 


100 


61 



Since only one o: the two minicomputer alternatives was evaluated in detail 
from the junior high school persp<jctive , a mora restrictive interprepation of 
relative suitability is required. At the very least, tne relative 
suitabilities shown in the tables above can be cjmpared to those for the 
senior high school to show how much more or less suitable SAS is to each 
school tvpe. The reader is strongly encouraged to compare the results 
reported here with those contained in a separatva report which deals with the 
evaluations of microcomputer based systems. 
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7.0 COMMENTS AND CONCLUSIONS 

The major objective of this evaluation project was to comparatively evaluate 
minicomputer based School Inf vormation Management Systems and, in the process, 
to determine the viability of their use by schools. 

Two software systems were evaluated against the same detailed set of criteria 
and in true minicomputer environments * 

Initial experiences of the project teams indicated that considerable 
development work was required (for both systems) to realize complete School 
Information Management Systems. Hardware and operating systems environments 
were found to be very powerful and stable, providing for good printing and 
multi-user functions. Whilst recent developments of minicomputer SIMS 
indicate that the amount of development work required has decreased, there is 
still a need for programming staff to support data communications and regular 
operation of the minicojiputer . 

Consideration of cost benefit and complexity factors leads us to believe that 
the minicomputer based systems which were evaluated through this project are 
not suitable for use by individual schools. For each of the .ystems 
evaluated, the combined rost of hardware and c^oft^-^are '*as in excess of 
$60,000. In addition, a Kner can expect to spend appr ximately two to three 
thourand dollars per year for essential hardware and software maintenance. 

Those considering the implementation of one of the microcomputer based SIMS 
alternatives which were tested through this work should carefully examine the 
process for determining product suitability and re-apply it to the raw 
evaluation H^ta from their particular perspective. Those who seek to identify 
other alternatives are encouraged to apply the principles of this process to 
the maximum extent possible. 

Between the completion of hands on testing and the production of this report, 
both systems which were evaluated have undergone further development hy the 
respective companies. Appendix 6 briefly describes some of the more 
significant recent developments which are known to us. 

In cl'^sing, it is noted that the project reported on herp is part of a more 
comprehensive evaluation of the distributed approach to school information 
management. A earlier report addresses the viability of a microcomputer based 
approach to school information management. 
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APPENDIX i 
GENERAL QUESl lONNAIRE 



This •'ocmneat wac distributed to schools for completion 
as an initial iaformation gatheriorr step in the process 
to develop evaluation and selection criteria for school 
information nutnagemeat systems. 
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EDMONTON PUBLIC SCHOOLS 
COHPUTL^.IZATION 0F~SCHObL ADMINISTRATIVE/INFORMATION SYSTEMS 



GENERAL QUESTIONNAIRE 



Background 



The Distributed Systems Services ream has identified a short list of compu- 
ter software packages specifically designed for the day-to-day student 
administrative requirements of individual schools. In order to facilitate 
the selection of the most suitable software alternative, for the EPSD from 
a Di Urict-wide perspective, the attached questionnaire has been prepared 
with a view of determining the relative importance of the type of inform- 
ation, system functions and features needed by the school(s). In addition, 
personal interviews will be conducted with each participating school in 
order to determine each school's specific information requirements, review 
the type and ditail of data needed by the school to streamline its oper- 
ations and idf.ntify any areas of concern. 

The questionnaire has been divided into two parts. Part 1 deals with the 
information needs of a STUDENT ADMINISTRATIVE SYSTEM and Part 2 addresses 
other information requirements that the schonl(s) may have. 

Part 1 - STUDENT ADMINISTRATIVE SYSTEM 

Each item ^s to be weighted in accordance to its relative importance to the 
specific institution completing the questionnaire, using the following rat- 
ing scale. 



NONE - Hot required. 



OPT - "Optional" 



a requirement not considered essential but 
for which preference may be given 



IMP - "Should*' - a requirement having a signif icant degree 

("Desireable") of importan ce to the objectives of the 
("Important") Student Administrative/Information System 



MUST - Mandatory 



a reguirement that must be met in a sub- 
stantially unaltered form in order for the 
software package to meet the schools vital 
information needs. 



Part 2 - OTHER INFORMATION SYSTEMS 



':3pl icat ions should be ranked in accordance 
computerize other are<:<^ of its operations. 



with the school's priority to 
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15 



NAMt OF SCHOOL (in full) 

Questionnaire completed by (Name) 

(Title) 



PART 1 

STUDENT ADMINISTRATION SYSTEM - INFORMATION NEEDS 

SECTION A - School records, student records, attendance recording/ 
reporting, student marking process and reporting 
requirements. 

General Overview of the System's Objectives 

A computerized student administrative system to resolve and streamline the collactinq, 
transcribing, maintaining and reporting of stucent data. It is to maintain student relat 
ed data, provide up-to-date information and prepare reports that are used by administra- 
tors, counsellors, instructors, students and parents. 

Informat io n Need - Relative Rating Scale Legend : 

Relative Importance 

Column Heading - NONE OPT IMP MUST 

Degree of importance - Not required Optional Important Mandatory 
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~ 2 - 



Application/Feature Description Relati ve I mportanc e 

NONE OPT IMP MUST 

1) Registration/Enrollment 

-Enterinq a student into the school and 

creating the student record 

-Registration/Enrollment confirmation notice 

-Other information needs (specify): 



2) Student Records 

-Demographic data e.g. name and address, pro- 
gram, type of instruction, m(^dica1 , class(es), 
timetable, medical , parents, etc. 

-History i.e. academic achievements, marks > 
course attemp s, etc. 

-Student coding e.g. 

- school ID# 

- EPSD & Alerta student ID # 

-Bus Information e.g. bus pass number, pick- 
up and drop off points, driver name, bus 
routes etc. 

-Interface/integration with your schoors 
accounting systeiri (in future) 

-Other (specify) 
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Application/Feature Description Relative Importance 



NONE OPT IMP MUST 



3) Student Attendance 



-Indicate the frequency that attendance is/ 
should bfi taken in your school e»g, every 
period (by class) once per day, twice per 
day, at homeroom time, etc. 



-How often do you need attendance reports 
e,g» daily, weekly, bi-weekly, etc.? 



-How much detailed attendance history does 
your school require to keep "on-line" for 
parent, counsellor inquiries e.g. 5 days 
history, 6 days history etc.? 



-What types of attendance reports do you need? 
e.g. by student, student by class/subject, 
student by day, exception reports etc, and 
how frequently do you require each report? 



4) School Reports 

-Directories/class lists 
-Labels (mailing) 
-Student ID cards 

-Schedules (student, teachers, rooms) 
-Other reports (specify) 
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Appi ^cation/Fpaturo Oescription 



Rel ati ve Importanc e 



NONE 



OPT 



IMP 



MUST 



5) Instructor Records 

-Personal and demographic information 
-Courses tauqht 
-Areas of specialty 
-Certificate number 
-Other (specify) 



6) Student Marking Process 

-Comprehensive editirtg and validation of student 
rarks prior to report card preparation e.g. mark 
verification, identification of student with 
unasbiqned marks Ptc. 

-Report card printing 

-Type of reports e.q. GPA's, honour lists, etc. 
(Please specify): 



-Other information needs (specify) 



-What is the maximum number of marks per course 
maintained by your school for a student e.a. 
4 mid-term marks, 2 exams a.id a final mark'? 
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Application/Featurp Description 



Relativp Importance 



NONE 



OPT 



IMP 



MUST 



7) Student Exams 



-Exam timetable builder 
-Exan. conflicts matrix 
-Exam schedules 
-Other (specify) 



8) Courses 



-Course number, short descriotion, detailed 
description (for annual school handbook), 
credit values, prerequisites, etc. 

-Other information requirements (specify): 
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SECTION 8 - STUDENT SCHEDULING 



Course requests, prerequisite verfication, request confirmation, student curricular coun 
selling, computerized scheduling, school start up registration, automatic generation of 
student fee sheets and printing of individual timetables. 



THIS SECTION IS AP°LICABlE TO HIGH SCHOOLS, 
JUNIOR HIGH SCHOOLS AND ELEMENTARY-JUNIOR 
HIGH SCHOOLS ONLY 
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SECTION B - STUDENT SCHEDULING 



Col se requasts, prerequisite verification, request confirmation, studpnr curricular 
counselling, computerized scheduling, school start registration, automaciu generati 
of -^nt fee sheets and printinq of individual timetables. 

Application/Feature De scriptjon Relative Importance 



!^^M^ IMP MUST 

1) Pre-schedi:iing 

-Comprehensive editing and validation of 
course requests e.g. prerequisite checkinq 
marks verification, ioentif ication of 
students with no requests, insutf ici e..t/ 
excessive credits requested 

-Preschedul inq reports e.g. course tally 

list, exception repo*^ts (students missing 
mandatory/compulsory courses) 

-Scheduling coi.flicts matrix 

-Other information needs (specify): 



-Other [rescheduling reports (specify): 



2) Master Schedule 

-Master timetable builder 

i) What course code would you prefer to 
use e.g. a school course code, EPSD 
course code or the A' -ta course code 



ii) Please specify ALL. of the scheduling 
units uspd by your school, e.g. semester 
full year, trisemester, six week section, 
quartermester, etc. 
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Application/Featut e Description P^latiye Importance 



NONE OPT m_ MUST 

iii) Please specify the followinq: 

Rot a: ion: 

Dayi per week: " 

Periods per week- 

used in your school's mast^er ti'metabTe. 



3) Student Scheduling 

-Completion of the student scheduling process 

before the summer br-^ak 
-Ability uO preassign sections 
-^bility for your school to assign scheduling 

priorities: 

-Automatic scheduling of an individual student 

i.e. mid-term transfer pupil 
-Ability to schedule groups of students 

i.e. unregistered last minute arrivals 
-Ability to 'uNSCHEDUlE" a student or qroup 

of students i.e. no shows, students that 

move aw^y during summer etc. 
-Restart capabilities e.g. reset assignments 

for a student and/or course 
-Course ^eguencing 

-Course weighting i.e. ability of the computer- 
ized scheduler to distribute course ^oads evenly 
so that a student is not scheduled to take an 
overload of difficult courses in the first 
semester and a qroup of relatively easier 
courses during the second semester 

-Blocking 

-Class balancing 

-':>c.nester balancing 

-Double room id-^ntiiy e.g. Physical Education 
all male/female class 

-Double oom identity for mixed classes e.g. 
Home Economics and Industrial Arts 



i) What are your p, esent scheduling priorities 
e.g. - lower grade stuuents fir^t and so 
on up to highest qrade? 



e.g. - single section courses before 
multiple section courses'' 



- CONTINUED ON NEXT PAGE - 
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A p: lication/Feature Description Re lative Importance 

NONE OPT IMP MUST 



e.q. - mandatory/compulsory courses first 
followGd by student preferences 
followed by uptions/alternatives? 



OR indie ite your priorities in the space 
be I ow: 



-Ability to r-jn schedules from more than one 
perspective e.g. single sections first the*^ 
mandatory courses etc. and mandatory courses 
f'rst and single sections last 

-Other information needs (specify): 



Reports 

-Student scheduies 
-Multiple conflicts matrix 
-Partially schedulpd students 
-Other (specify): 



4) School Start Up 

-Generation of fee sheets 

-Ability to schedule all i.rw students (un<^xper^- 
ed enrollments) only i.e. the schedules for all 
previously registered studerts would not be 
affprted 

-Preparation of timetables in gric' format 

(ctudents, teachers and rooms) 
-Class lists 
-Other (specify): 
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iKE FOLLO'.'ING IThfIS ARE PERCEIVED TO CE APPLICABLE 
TO SCHEDULING IN JUNIOR HIGH SCHOOLS ONLY 



Application/F ea ture Description Relative Importance 

NONE OPT IMP MUST 



5) Special Scheduling Requirements 
of Junior High Scnools 

-Blocking of course options 
OR 

Scheduling students requesting same group of 
options into the same class or homeroom 



Blocking of 2-3 sections of the same course 
in same time block e.g. Math or Language Arts 

•Homeroom identity grouping for Language Arts, 
Social Studies, Science, Math 



-Ability to handle option courses with varying 
lengths of instruction e.g. French as an option 
requires four periods per week whereas other 
options require three periods p^r we^k 



-Back to back time tabling for double classes 



-Ability to handle variable time slots by 
course subject e.g. six periods of Language 
Arts, five periods of Math, four periods of 
Social Studies, etc. 



-Other reguirements or unique characteristics 
associated with the scheduling process for 
your school 



Please specify any idiosyncracies in your 
schools allocation of subject time p.g- 
difterent/x'ariable periods (standard period 
= 40 minutes, course x ha^ a period of 
30 minutes, etc. ) 

165 
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PART 2 - OTHER INFORMATION SYSTEMS 



Please rank the imoortance of each application in accorda?^ce with your 
schools priority to computerize other areas of its operations, e.g. 1, 2, 3 
etc., from most important to "'east important. If en application is not 
perceived to be a requirement indicate a priority of '0" (ze-^o) or "NIL". 



Implementation 

Application/System or Sub-system Priority 

Acco ;ts Payab^'e 

Accounts Receivable 

F'jdgetinq 

Computer Assisted Instruction (CAI, CAL, CML) 

Cost Accounting 



Financial (General Ledger and Finat.cial Statemf^nts) 
- also indicate whether or not you require 
commitments to be included i.e. encumberance 
accou'^*^ i ng Yes or No 

Fixed Assets 

Inventory Control 

Li' ^ry Services 

Pur chasi nq 

Word Proc3Ssing 

Work Orders 

Other (Specify) 
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APPENDIX 2 
INTERVIEW GUIDS AND DBTAILBD CHECKLIST 



This document was used to facilitate a follow-up 
i'lterview with surveyed schools to clarify and confirm 
their r. senses to the general questionnaire. 
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EDMONTON PUBLIC SCHOOLS 



COMPUTERIZED INFC^MATION SYSTEMS NEEDS OF INDIVIDUAL SCHOOLS 



INTERVIEW GUIDE AND DETAILED CHECKLIST 



SECTION A - School records, student records, attendance recordinq/ 
reporting, student marking process and reporting 
requirements . 



Application/Feature Description Relative Importance 



NONE OPT IMP MUST 



1 ) Reg i s trat i on/Enrol ]mer\t 

Use questionnaire. 



2) Student Records 

-Personal /Demographic 

-Courtesy name 

-Academic 

-Activities 

-Medical 

-Program 

-Type of instruction 
-Timetables 
-Courses and classes 

-Student history to include all courses/n?rks 
while in the school 
OR 

T5oes the school want to include all marks the 
student has achieved while in a similar level 
of school e.g. High School, Grades 10-12; 
Junior H^gh, Grades 7-9 etc. 
Specify level of detail needed below: 



-Complete hibcory of each course that each 
student attempts, including tne number of 
attempts 



-Parent data up lo a maxirrum of 2 parents 
per student 
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Application/Feature Description 



NONE 

-Is a limit of 2 parents sufficient 
Yes or No 



-Bus pass number 
-Bus route(s) 
-Driver name 

-Pick-up and drop off points 

-Student ID # (indicate whether the school 

has a preference for its own unique ID 

system or the EPSD ID #) 



-Multiple ID'S for cross referencing and 
interface with EPSD and Alberta 



3) Student Attendance 

Use questionnaire. 



4) Schuol Reports 

Use questionnaire. 



5) Instructor Records 
Use questionnaire. 



6) Student Marking Process 

-Report cards prepared by school rather 

than I SB Yes or No 

If Yes indicate level of importance 



-Student marks proof listing for verification 
before production of report cards 

-Student transcripts 



7) Student Exams 

Us^ questionnai re. 

o 
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Application/Feature Description Relative Imoortance 



NONE OPT IMP MUST 

8) Courses 
-Term weight 

-Included/exrluded from report card averaqe ~ 

-Pass/Fail mark 

-Otner (specify): 



SECTION B - STUDENT SCHEDULINb 



N.B. THIS SECTION SHOULD BE COMPLETED FOR HIGH SCHOOLS AND JUNIOR 
HIGH SCHOOLS ONL'^ 



App lication/Feature Description Relative Importance 

1) Pre-scheduling 

-Student course/proqram/curricul um counsel! inq 
list 



s verification as part of prerequisite 
lecKing e.g. 49% in Math 10 is not acceptable 
for entry into Math 20 course but is acceptable 
for Math 23 

In this case should the student be advised 
of his/her options before the scheduling 
simulation i.e. repeat Math 10 or opt for 
Math 23? Yes o^ No ? 



-Ability for the individual student to 
identify his/he*^ 

a) mandatory/compulsory courses 

b) preferred course requests 

c) preferred alternatives 



CONTINUED 
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Application/Feature Description 



Relative Importance 



NONE 



OPT 



IMP 



MUST 



-Ability to conduct prerequisite checking for 
students from another school within the ERSO 

-Ability to handle co-requisites 



-Ability to add student records from another 
EPSD school into your microcomputer e.g. 
transfer student, graduate student from 
a feeder school etc . 



2) Master Schedule 

-Current Semester 
-Current Year 
-Future Semester(s) 
-Other (specify) : 



3) Student Scheduling 

-Access to scheduling alorithim e.g. logic, 
parameters, scheduling resolutions, options etc 

-"Teacher Link Courses" e.g. in the instance 
where a teacher is instructing English 10 
ard Social 10, a common core of students 
should be scheduled to this teacher for 
both courses (subiects) 



-Arena schedul i ng 

-Student section selection (preference) 
-Student instructor selection (preference) 
-Reduced term requests i.e. scheduling a 
student into, say, uhe second semester of a 
full year English course in order to improve 
his/her grade without repeating the first 
semester which he/she passtd satisfactorily 

-Speofic term requests e.g. Biology 10 in 
fi'^st sof^ester and Biology 20 in the second 
semester 
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Appl ication/Feature Description Relative Importance 



NON_E_ OPT |MP MUST 

-Other requirements for an in- house computer- 
ized scheduler: 

- use data from questionnaire and interview 

4) School Start Up 

Use questionnaire. 



5) Special Scheduling Requirements 
of Junior High Schools 

Use questionnaire. 

ENSURE THAT THE JUNIOR HIGH SCHOOL IDENTIFIES 
ITS UNIQUF NEEDS AND DEFINES ANY ITEMS OR 
AREAS THAT DIFFER FROM THE NORM. 
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PART 2 - OTHER INFORMATION SYSTEMS 



ACCOUN T S PAYABLE (A/P) 

1) Open item or balance forward 

2) Does the school issue its own A/P cheques? 

If Yes how many cheques does it issue per month on the average? 

3) What is the average number of General Ledger distributions oer vendor ice? 

4) If the school has indicated that the computerization of its Accounts Payable applica 
tion is a need, obtain a general description of what the school expects fron an auto 
mated system e.g. type of reports, statistical analysis, breakdown of A/P expenses 
(how?) etc. 



5) Should thp school's purchase orders be included m the A/P system to rpflect commit- 
ments? 
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ACCOUNTS RECEIVABLc' (A/R) 

1) Open item or balance forward 

2) He ' many invoices does the school issue per month? 

3) Does the school issue monthly statements for unpaid accounts? 



4) Why does the school want to autcrrate its A/R application? 

e.g. expected results, type and frequency of reports, revenue analysis, etc.? 



BUDGETIN' 



If computerization of General Ledger and Financial Statements are a need identified by the 
school suggest that the Budgeting application should be included as an inteqral part of 
the former system. ^ 

1) What information and/or statistical breakdowns do we n-ed for budgeting e.g.: 
-student count by category or progran (ESL pupils, native children, etc.) 

-previous years *^inancial statements by department, proqram, cost centre, etc. 



o . 1 7i 

i£J£ (113) 



- 3 - 



FINANCIAL (GENERAL LEDGER AND FINANCIAL STATEMENTS) 

1) Should commitments be includpd in the schools financial reports i.e. encumbera-^ce 
accounting in order to ensure that the school knows where it stands in relation co its 
budqet? 

For example: 

Total budqet - (actual expenditures + PO commitments) = the balance available in the 

budget 

2) Does the school require any interface/integration between its financial and student 
administrative system? 

3) What type of G/L coding structure does the school envision? 

e.g. EPSD G/L code 
or 

The schools own G/L code 



4) How many G/L accounts does the school now use? 
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0) What objectives is the schoo^ seeMng through compL,ter i zat ion of its financial mform- 
at'on i.e. type and frequency of re-^or-ts. bjdqet analysis etc. 



6) riov, -^any different fund sources o.ies tne school have;' 
e.g 

EPSL funds (from provinc'i and municipal taxe-,) 

TRIM funds (Text book rental, fees and instructional materials) 

Special pro.iect funds derived from school initiatives ;.e. car washes, 
bottle cnve e^c, for field trip', (qlee dub, band, socce- tea-n) 

Other 

7) Coes the school rtquire s^o^rate financial str em^nts for each fund i-. is resoonsible 
for? 



8' Are consolidated financial statements r^iuired by tlie school? 



9) What other financial information does the school need? 
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COMPUTER ASSISTED INSTRUCTION 

Obtain a qeneral d^jCripticn of the schools ne^^s and '^^x pec tat ions in this area. 



Co st Accounting 

1) Cou^d the schools requirements in this area be included in the general ledger firau- 
cia^ statements. If not obtain a conceptual overview of the type of cost accounting 
information required by the schoo"'. 
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FIXED A SSETS 

1) What aeneral class of it'^ms does the school want to include in this eppl iCc.t ion'? 

2) Are the school's fixed assets currently tagged with a permanent identifier^ 

3) Approximately how many items aoes the sc'iool estimate it would include in its automat- 
ed fixed asset sysem? 

4) Obtain a brief cur.ceDtuai rview of what the school expects irom a fixed asset 

5) What type and frequency of reports c^nes the school need ^rjm this system* 
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INVENTORY CONTROL 



1) Does the sc'iool have d centi-al sto^dMe facility? 



2^ What typet'o) of inventory and how ipany items, issues and receipts does the school wish 
to control ? 

e.g. Aj'toTO^ T ve s'r^o^ 

Wood shop 

Home Economics, etc. 



3) Does the school need to integrate iis purchase orders with inventory control? 



4) What does tht school need in the way of an inventory control system^ 
Describe briefly. 
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LIBRARY SERVICES 



1) How many books does the school estimate to have in its library.^ 



2) Computerized needs 



-Cross Reference by 



Author? 
Title? 
Publisher: 
Subject? 
Key words? 



-Checkout/Renew?! 
-Returns 

-Overview not '•ces/1 i sts 

-Fines 

-Other 



3) Statistics e.g. usace? 



4) Crbtai'^ a general conceptual overview of the schools needs in this area. 
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PU RCHASING 

General requirements, volumes and brief ccnceptual ove'^view. 



WO RD PROCESSING 

Estimat'^d volumes, frequencies 

Type of word processing needed i.e. 
personalized letter:> 
mas. mailings 
reports 

general correspondence 
Try to determine an estimate the school's current work loac^. 
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WORK ORDERS 

Estimated Volumes 

How are they handled now? 

Are W/O's costed out e.g. 

laboiT S 
material $ 



Are W/O's integrated into the financial <^ystem7 



General conceputal overview and description of system needs. 
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APPENDIX 3 



DETAILED SCORING COKPARISON FORM 
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eVALUATION 


CRITERIA ITEMS 


PACTOk 


PRODUCT 


SCHOOL RECORD? 




SCOPE 4 






PUHCTIOH 


Pre-*Rc?gi8trat ion/Enrollment 






Create student record 






^^Ri*tration conf Irfnatlon nnrif-m. 






Feeder school confirmation novice 






TOTAL Pre-Reglstratlm/Enrollwot 






Detailed Data Item 






Student Infomatlon 






Instructor Inforutlon 






Course infomtlf 






TOTAL Detailed Data Itew 






Reporta/Inquiriea 






TOTAL Raporta/Iaqalrlea 






TOTAL SanOL RECORDS 






SCBEDOLIIC 






Hanual achaduiing (Arena Scheduling) 
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WEIGHT 
(W) 



15 



PRODUCT ] ; 

SCORE WEICHTEO 
SCORr 
(S) (W T. S) 



PRODUCT 2 : 

SCORE WEICHTEO 
SCORE 
(S) (W X S) 



SCORE WEICNTCr 
SCORE 
(S) (W X S) 



20 



25 



15 



45 



25 



25 
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EVALUATION 
FACTOR 



CRITERIA ITEMS 



Pre-schedulln \ 

Cou^'se Requests 

manua^ entry 
automated entry 

Edit and validation of course requests 

Pre-schedullng reports 

TOTAL ?re-Scheduling 

Master schedule builder 

Capability to build a master scheduler 

manually 

au tomatlcaliy 
Capability of handling a variety o* 
scheduling units 

User defined timetable rotation/tumble 
Flexible number of periods per day 
Capability to specify exclusive male or 
female sections 

Capability to maintain current and future 
year/semester iiasiev schedules 

TOTAL Haster Schedule Builder 

Scheduling Process 

User defined scheduling sequence 

Unschedullng of no-shows/wlthdrawals 
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WEIGHT 
(W) 



_J_ 
30 



PRODUCT 1 



SCORE 



WEIGHTED 
SCORE 
(S) (W X S) 



PRODUCT 2: 

SCORE WEIGHTED 
SCORE 
(S) (W X S) 


PRODUCT 3: 
SCORE WEIGHTED 
(S) (W X S) 
























9 



9 



10 



8 



6 



5 
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EVALUATION 
FACTOR 


CRITERIA ITEMS 


WEIGHT 
(W) 


PRODUCT 1: 


PRODUCT 2: 


PRODUCT 3: 

SCORE WEIC:»TED 
SCORE 
(S) (W X S) 


SCORE WEIGHTED 
SCORE 
(S) (W X S) 


SCORE 
(S) (W X S) 


L_ 


Scheduling of Individual student or small 

groups of students 

Capability to reset all students or 

partially scheduled etude. its 

Capability to lock scheduling assignments 

for all students or a group of students 

Restart capability 

Course weighting/semester balancing (ensure 
t/en course load for students) 
Blocking of courses 
Section balancing 
Class balancing (males-females) 
Capability to keep scheduling open after 
school start while starting to use the 
attendance laodule 

TOTAL Scheduling Process 

Scheduling Reports/Inquiries 

Junior High Scheduling Requirements 

Homeroom grouping for core subjects 
Capability of scheduling any course in any 
combination and number of time periods 

TOTAL SCHEDULING 

STUDEKT ATTENDANCE 

Entry of Attendance Data 

manual entry 
automated entry 


6 








8 








8 








8 









8 








7 








8 




_ 


^ 










9 









11 




„ 




10 




... 




9 








10 
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tVALUATION 
I" ACTOR 



CRITERIA ITEMS 



Multiple user-defined absence types 

Capability to record attendance data at 
various intervals 

At tendance history 

At tendance re ports/ inquiries 

TOTAL ATTENDANCE 

STUDENT MARKS 

Entry of marks data 

manual 
automated 

Marks data 

Student Exams 

Exan timetable builder 
Exar Reports/Inquiries 

Reports/Inquiries 

TOTAL STUDENT MARXS 



PRODUCT 1 . 

WEIGHT SCORE WEIGHTED 
SCORE 

(W) (S) (W X S) 



PRODUCT 2 : 

SCORE WEIGHTED 
SCORE 
(S) (W X S) 



PRODUCT 3 ; 

SCORE W^.IGHTED 
SCORE 
(S) (W X S) 



0 



5 



10 
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EVALUATION 
FACTOR 



EASE OF 
DSE 



TECHNICAL 
CONSIDERATION 



SUPPORT & 
SERVICES 



CRITERIA ITEMS 



UTILITY FUNCTIONS 

Backup/Restore 
Security /Controls 
TOTAL UTILITY FUNCTIONS 

GRAND TOTAL, PRODUCT SCOPE AND FUNCTION 



GRAND TOTAL, EASE OF USE 



GRAND TOTAL, TECHNICAL CONSIDERATIONS 



GRAND TOTAL, SUPPORT & SEF.tfTCES 





WEIGHT 
(W) 


PRODUCT 1 
SCORE WtlGHTED 
SCORE 
(S) (W X S) 


PRODUCT 2 
SCORF, WEIGHTED 
SCORE 
(S) (W X S) 


PRODUCT 3 
SCOKE WEIGHTED 
SCORE 
(S) (W X S) 




12 












8 
















20 






































1 
















60 












































1 










L 


i 




1 


80 


































1 








on 






















70 




































70 
















1 
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EVALUATION 
FACTOR 



PRODUCT 
QUALIFICATIONS 



VENDOR 
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CRITERIA ITEMS 
(W) 



GRAND TOTAL, PRODUCT QUALIFICATIONS 



GRAND TOTAL, VENDOR 



WEIGHT 
(S) 



PRODUCT ! 



SCORE WEIGHTED 

SCORE 
(W X S) (S) 



PRODVn* 2: 



SCORE WEIGHTED 

SCORE 
(W X S) (S) 



PRODUCT 3: 



SCORE WEIGHTED 

SCORE 
(W X S) 



80 



80 



70 



70 
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APPENDIX A: MID-AMERICAN PA?S Screen and Program Functions 
Distributed Systems Team Develop'jd Programs 
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MAINFRAME 
PR 
SYSTEM 



STUDENT 
REQUESTS 



I 



SCHEDULING 
SYSTEM 



DEMO 
CRAPHICSl 



PROGRAMS 



PROGRESS 



PUPIL 
RECORDS 
SYSTEM 



STUDENT 

PROGRESS/ 

HISTORY 



ABSENCE 






ATTENDANCE 


^ 


SYSTEM 


UPDATE 
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PROMPT DATA 


BASE 


FACIL ITIES 




-SPECIF ICATICrJ- 




-EDIT TNP- 




--EXECU1 lON- 


-EXE 


Al - FCD 


Bl 


- FCB/S:CREEN 


Ci 


- DATA ENTRY 


Dl - 


A2 - AMEND 


B2 


- AMEND 


C.?. 


•- rTLE AMEND 


DT - 


A3 - CONVERSION 


BZ 


- CONVERSION 


CZ 


- FILE CONVERSION 


D3 - 


A4 - INOUTRY 


B4 


- INQUIRY 


C4 


-- FILE INQUIRY 


D4 - 


A5 - REPORT 


B5 


- REPORT 


C5 


- RnPORT WRITER 


D5 - 


A6 - PROCESSOR 


B6 


- PROCESSOR 


C6 


- TRANS PROCESSOR 


06 - 


A7 ~ MENU 


B7 


- MENl) 


C7 


MENU MANAGER 


D7 - 


A8 - SORT /MERGE 






CG 


- r.ORT /MERGE 


D8 - 


A9 - EXTRACT 






C9 


- FILE EXTRACT 


■J 9 - 


AlO - SCREEN 










rio - 












Dl 1 - 












D12 -- 












013 - 


f-INTER OPTION: 




(E = END 


PROMPT) 


D14 - 



VOLUME: SCHED 



-EXECUf lON/UTILITIES- 



FCB LIST 
FILE MAINTENANCE 
FILL COPY /RENAME 
FILE INDEXER 
FILE SEQUENCER 
FILE DELETE 
FILE EMPTY 
SORT/MERGE LIST 
EXTRACT LIST 
FILE MOVE 
SORT (1 FILE) 
MERGE (2 FILES) 
PARMFILE MANAGER 
CHANGE VOLUME 
ENTER PROGRAM 



D15 - 



'PROMPT' IB THE REGISTERED TRADEMARI OF MID AMfivTCAN rfiNTF.'OL CORPORATION 
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UPDATE STUDENT RECORDS 



VOLUME: WORK 



1 — ENTER DEMO INFORMATION 

2 — NEW STUDENTS 

3 — RETURNING STUDENTS 

4 — CHANGE STATUS 

5 — DELETE STUDE JTS 

6 — STUDENT CHANGES 

7 — ADD /DELETE COURSES 

8 — UPDATE JP ID tt 

9 — GET DATA FILES 

10 — AOD JP ID TO NEW STUDENTS 

11 — STUDENT PROGRESS RECORDS 



12 
13 
14 
i5 
16 
17 
18 
19 
20 
21 
99 



— END OF BATCH PROCEDURES 

UPDATE MAIN FRAME 
UPDATE SERIES 1 MINI 
UPDATE ATrENDMNCE FILES 

— PRINT CLASS LISTS 
-— CHECK STATUS 



END 



CHECK 
wHECK 
CHECK 
CHECK 
MENU 



BY STUDENT ID# 
BY SURNAME 
BY EPSB ID# 
PROGRESS REC 



OPTION ? 
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SCHEDULING PHASE 

1— SCHOOL DATA 

2 — ADD NEW SCHOOL 
P 3 -- PRINT SCHOOL MASTER 
S 4 — CHANGE OR DELETE SCHOOL 

5--INSTRUCT0r DATA 

6 — ADD NEW INSTRUCTOR 

7 — PRINT INSTRUCTOR MASTER LIST 
a -- CHANGE OR DELETE INSTRUCTOR 

OPTION ? 



II PROCEDURES VOLUME: SCHED 

9 — MASTER SCHEDULE 

10 — ADD SECTION TO MASTER SCHEDULE 

11 — PRINT MASTER SCHEDULE LIST 

12 — CHANGE/DELETE COURSE SECTIONS 

13 — SPECIAL REP-ORTS 

14 — INSTRUCTOR CONFLICT ANALYSIS 

15 ~ ROOM CONFLICT ANALYSIS 
99 — END MENU 
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SCHEDULING PHASE III PROCEDURE VOLUME: SCHED 

1 

2 - INITIALIZE SCHEDULING MASTERS 'o " ^ ^REA^F P R □ C 

3 — — — _ CREATE DEFAULT STUDY HALLS 

4 — ~ ~~ ENTER STUDY HALL SECTIONS 

5 __ ~~ INITIALIZE STUDY HALL COUNTS 

6 - SCHEDULING RUN ~~ -~ qpHrnnPc^o^' '"''^^ 

7 SCHEDULE STUDY HALLS 

8 — SCHEDL. RESUlTq S^~" ^'^'^^'^ ^^^^^^ ^^^^ "-IST 

9 — MASTER SCHEDULE TALLYS %yZZ ^^^^^^^ ^'^'•^^^ ^^^^^ SCHED. 

10 — LAST SCHEDULES PRODUCED -R - w a m n 

11 — SCHEDULES WITH CONFLICTS t^t " ^ ^ ^ ^ SCHEDULING 

12 -- PARTIAL SCHEDULES nu^ ^° SCHEDULE 

13 — ^ntuuLLb .^n — CHANGE EXISTING SCHEDULE 

14 — FINAL RESULTS IZ q c 

15 - STUDENTS NOT SCHEDULED ^ I- p.^rJi I., ..ncxeL^' ° ^ ^ 

16 — COMPLETE SCHEDULE DUMP -1 ^^^^^ ROSTERS 

17 - FREE PERIOD ANALYSES ^- ~" ^'^^''^ "^'^^^ SCHEDULES 

18 — ANALYSIS ^ __ ppjNT TEACHER SCHEDULES 

99 — END MENU 

OPTION 
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STUDENT ATTENDANCE SYSTEM VOLUME: STUDT 



ENTER ABSENCES 


15 


— GENERATE ABSENT REFORT 


BY PERIOD 


16 


ABSENCES -CURRENT DAY 


BY STUDENT IDtt 


17 


EXCUSED ABSENCE LIST 


BY EXCUSED ABSENCES 


18 


AD HOC ATTENDANCE REFORTS 


CHECK STATUS 


19 




BY STUDENT ID# 


20 


— EMD OF DAY FRGCEDURES 


BY SURNAME 


21 


UNVERIFIED ABSENCE LIST 


BY EFSB ID# 




FREPARE FOR NEXT DAY 


CHANGE STATUS 


24 


— END CF REFORT PERIOD 


CURRENT DAY 




SAVE DATA 


FAST DAY(S) 


26 


SET NEW PERIOD 


FUTURE DAY(S) 


27 




FIELD TRIF 


28 


— PRINT CLASS LISTS 



99 — END MENU 



JP SCHI-DULING RUNS 
198A - 85 



DATE 


NUMBER 


MAINFRAME 


MINICOMPUT&R 




OF 












STUDENTS 


SIMUL 


TRIAL 


SIMUL 


TRIAL 


JUNE U 


1,775 


319 


369 






JUNE 18 


1,775 


266 


321 


263 




JUNE 23 


1,7P2 


203 


259 


207 




JULY 3-4 


II III 1 ■ I 

1,797 


217 


257 


210 


260 


JULY 30 


1,800 


203 


2^9 




227 


AUG. 3 


1,800 


193 


228 


193 


231 


AUG. 13 


1,800 


35 


71 




80 


AUG. 16 


1,800 


41 


77 




81 


AUG. 20 


1,80A 








76 


AUG. 22 


1,624 




117 




111 


AUG. 23 


1,823 




107 




104 


AUG. 29 


51 








19 


AUG. 31 


38 








19 


SEPT. 4 


18 








3 


SEPT. 7 


12 








8 
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iPPT^.NDIX 5: IBM 4341 and SERIES I to VAX 11/725 
Data Transfer 
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[ji- LC^hJ rb:Ni :d 



1 . 

3. (. 

4. r 

6.C 
/.<. 
8. C 



Ir^traduci] on 

hai D-f r ame to SERILL-I/ 1 \r ari<- t r r 

SERIES/ 1 Dc?Lc^ Convert] on 

SERIES/ 1 t(j IHM/PC: Trans+fpr 

]BM/PC Data Conve^rssion 

DEC RAINBOW iOO to VAX- 1 J Iran-sfer 

VAX-l 1 Data Conver^^j on 

Gum/?>ary and Re5ulti5> 



Lr^j} \Jt Ah'h'ENDJLL 



A. 1 Overall Cnmaiuni cat i on Elow Dj agr 

A . 2 Dat a Layouts 

A. ::. 1 IBM 4:.4J Data 
A. 2. 2 SERIES/ 1 Data 
A. 2- 7. IE^ri/PC Data 
A. 2. 4 VAX-11 Data 



A. 



am 



A. 4 VAX RMS IJtilit/ For Data C 



unvk'jr SI an 
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l.U INTRODUCTION 



To provide a realistic environment -for lffL-,tiny the School 
Administrative System (SAS) from SIERRm, the^ f.cheduli ng subsystem 
in particular, the SAS data basa v*ias I: o be initialized with 
student demographic and course request data from Jasper Place 
High School 83/84 school year- This data had bee?.i downloaded from 
the IBM 4341 mainframe to an IBil SERIEB/1 minicomputer. The 
initialization process began with retrieving data relevant to the 
SAS system from the SERIES/1 and downloading the data to an 
IPM/PC. T.iis data was restructured according to S^ " record 
formats and placed on diskettes which could be rec-ii uy a DEC 
RAINBOW 100 microcomputer. Using - software communication 
package, '=>OLY-COM, a RAINBOW - on,puLer trr^nsfered the data to the 
VAX 11/725 minicomput-t . Finally, the student data were loaded 
into tht^ SAS data base by using the VAX Record Management 
Servi.' «:. utility. A graphic representation of this process was 
given in Appendix A-1. 

The method used to transfer data to the VAX system required 
manual intervention at various stages. However, this method 
sufficed for limited applications *-:>uch cv^> cr-e^atmq test data. The 
Jasper Place High School student data for B:'/B4 alrec.dy e?tisted 
in a file in the IBM SERlES/1. Using a HERIES/1 utility, 
"PROMPT", the required student dat^ could be easily retrieved and 
formatted ^vccording to SAB requi r eaien t . 1 hus processing of Pupil 
Records at the mainframe and Hubsequent. cJc-i'^nl uadi ng from the 
mainframe were eliminated. The downloc^ding procedure from 
SERIE5/1 to IBM/PC had been thoroughly tested. Once downloaded to 
a PC file, other conversion procedures could be perfor'med on the 
data as required. 
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oisB'-ST COPY AVAILABLE 



2.0 MAINFRAME TO SERIEB/1 TRAN'^rflR 



Student dpmngraphir and caur<!r>e request data -for all Edmonton 
public schools are maintajned as part of the Pupj 1 Record (PR) 
database in the IBM/4341 main-frame. A user program was used to 
selnct from the PR records data which were rc?] evant to the school 
administrative system running on the IBM GERlES/1 computer. The 
selected data were placed in a punch -file -for dowr oading to the 
SERIES/1- 

The SERIES/1 was connected to the main-frame through a leased line 
using point to point b i synclircinous commun i ca r. i on . A VSERJE 
•facility in the SERTES/1 L^nabled it to function as a remote job 
entry station to the mainframe. The selected F='R data file was 
then downloaded to a p»^e-al 1 oc ated file in the SERIES/l. Because 
the data were created a*^ a punch f i j e, thref? records were needed 
for each student- A program was> run to organi::e each student's 
data into one recrjrd. 
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BEST COPY AVAILABLE 



3.0 SERIES/ 1 DAie CUNVERSION 

The SERIES/1 file which was ne.ed as i he «-^oLirce for SmS dat a 
contained both sturjent demographic and course rpques=t data (see 
Append! V A. 2. 1 > . In SAS\ ^ystcTi c^tLidrnt derrio-^r ?phi r data and 
course reque?st data were maintained a?5 i^^eparatc-? -files (see 
AppendiJt A-2.4). Hence be-fore the<:,e data could bf£^ loaded into the 
SAS data base Lhey must be (.converted to coniorm to SAS record 
formats- 
Several limitations influenced the overall data conversion. 
First, while the SAS student records were characters long, 

only 79 character records uould be properly downloaded from the 
SERIES/ 1 to an IBM/PC. Furthermore, the ma;{imum record si^e in an 
IBM/PC sequential file was 255, and the maximum record iizb which 
could be transfered from a DEC RAINBOW lOu to a VAX 1/725 using 
the POLY-CGM utility was 254. To overcmje this problem, several 
programs were used in the t-IRIEB/l to select data from the 
SERIES/1 file to create four student record files. For each 
student, a stuaent record was created in each student record file 
(see Appendix A. 2. 2). These four files was downloaded to an 
IBM/PC ,.nd subsequently mergetJ to form a i-itudenc fjle. The 
resulting student record was 254 characters, long. Fortunately, 
the remaining fields in the SIERRA student record were not 
mtical to the test environment and could he initialized by the 
RMS utility to spaces. 

The second major limitation jn the overall data conversion wa _ 
thF lac^ of progr.-i.nming facility in the RAINBOW lOu anu tl 
VAX 11/725 in particular. Student data must be , -ocessed in the 
SERIES/1 and the IBM/PC:. Because of . >e SERIES/ 1 utility 
"PROMPT" which required minimal f?ffort to usc>, the SERIES/1 was 
used to perform data . . jni pul at i on as much as possible to minimire 
the amount of pi jgramming on the IBM/PC. 

PROMPT" was us€>d to produce the? four 'itudent rd files and 

:he course request files for downl xng to an IBM/PC. These 
flies wer^e create- 5 rerDor+-:b. 1 he source data of these reports 
c from the student demographic and course requests data file 

the SERIES/1. To create a report, it must first be defined 
using the "DEFINE REPGR7 " opt) on. A report definition consistc?d 
of information such as report name, type of output (print or 
video), source file name, source data to be reported and data 
position on report. For downloading video output must bf» 
specified. Each data file in the system must be identified by 3^ 
FCB (Fi le Control Blocf ) whi ch contained information such as 
r&cord length and data field attributes. Each data field had 
associated with it a sequence ntimber. Source data to be reported 
were specified using their sequence numbers. Once a repor-t had 
bpen defined, the "REPORT WRITER" could be uc^(-d to qenprate the 
report. 

A conversion step was requir*ed prior to reporting if the original 
source data were not jn the proper form?- (ip. date? was MMDDVV 
instead of YYYYMMDD) or if field'i, on ropori ncvda.l i n 1 1 1 al i r at i on 
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(le. assi ^ning a constant Vril I'D £^ re?pot'-ted field). "DEFINE 
FiJE<" was per -f or (n*--^d to dFj^ j r^f^ the£^ ro^-^ulting +rc>m th^ 

conversion. "DEFINF C0NVtiKSU3N" was pterf or mcr^ci to spe?cx + ie?d the 
conversion rules and the files involved. Alter a conversion had 
been run, the report procedure was use^d to create- a report based 
on the converted -file. 
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"^•^-^ SERIEB/1 TO IE<M/hC TRANSFFiR 



An IPM/F'C was connected to ihi^ SE-KJES/l u'l.ing a KblJ.j inter4c-^ce. 
A 3101 Emulation Program running on the PC enauied it to -funct 
a?b a 3101 terminal to the 5ER)ES;/L. I hff F-'L coiiid also save 
screen display in a -floppy di'^>}ette file. '\h 'icipahj / was 
used to transfer data -from the SSER Iff -3/1 h^^ PC. 

To downloaiJ a student or coi ' file, e F'C was started as a 

Lermmal to the ; ' ' '_^/l. T'w "•GRT WK*[TER" of "PROMPT" waB 

invoked to qer- e a rr;-, t. Since the report output was defined 
*s vidGO. i'.e report would btf dir^plaved on sscreen. Immediately 
rifter ' -rinQ the report reque!H>t and prior to any output being 

displayed, the system must be? interrupted by pressing the CTRL 
and no keys. A list o-f options would be di «5pl aye-'d . The "SAVE" 
option would be chosen and followed by enter 3 ng the file name 
under which the displayed report would be H»aved. The system then 
resumed with displaying and saving the report. After a screen of 
data had been displayed the system required the pressing of the 
entry I' ey to continue. When end of report was reached, the CTRL 
and FIO l-eys were pressed to interrupt the system and to select 
the "END" option to terminate saving of diTp^layed data. If this 
step was omitted, the system would continue to save displayed 
data into the file. Pressing the enter ^ ey returned the system to 
"PROMPT". 

This method of downloading had its limitations. The report record 
length should not be greater than 79 be?cause onJy thosie 
characters would be saved. To ensure all the data would be saved, 
there must be sufficient free spcXif-? on the disK Once downloading 
had started, there was no provision for e:r tending the saved file 
to another disk. During the downloading the enter ^ ey must be 
pressed after every screen o-f data tu^d been displayed. 
Downloading of large files becaaie rather ' ous. Another 
nuisance was that system prompt av -"^g^- ^"^nd blani Mnes were 
saved with the data. lln- down 1 oadeM.1 -t ) 1 must be further 
processed to removC' vi^ese "garbage' dat«3. 
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5.U IBM/ PC r^Arrj CONVERSION 



T'.^-^ downloaded student and course request data were processed on 
an IBM PC/XT to forms appropriate -for loading xnto the SAS data 
base. A program, STUDFM.BAS, was used to remove the garbage data 
created in the files during downloading- A program, sf UDPTCH. BAS, 
merges the four student f ile«£> to a single student file (see 
Appendix A- 2. 3)- Because thf? res^ultmg student file was too large 
to fit onto a floppy dis^:, a program, STUDCDPY. BAS, was used to 
separate the student file into thre floppy dis^s. Another 
program, STUDREDU. BA3, was use(^ to adjust the course request 
data. Separate course codes were assigned to Phyiscal Education 
classes for male and for female students. Section codes were 
deleted from the course codns. (See Appendix A-2.3 for resulting 
record formats and Appendix A- 3 for program listings) The final 
versions of student and course data files were written onto 
floppy disks which had been formatted as single sided and eight 
sectors per track. Hence these data became readable by a DEC 
RAINBOW 100 mi co-computer . 
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6.0 DEC RBl^iQw 100 rn VAx^ii IK'Amsf^r 

The FxAINBOW was used to interface? data transUT from the IBK/PC 
to the VAX 11/725. The RAINBOW was con.)ecteJ to the VAX through a 
sc?rial inter-face. To perform the data transit c-*r, the RAINBOW was 
booted as a stand alone sy<htem operat;ng under NS-DGS. The PC 
files created on special formatted dls^etLes were read by the 
RAINBOW and transfered to the VAX using POLY-CGM. 

POLY-COM was a communication software package tor installation in 
a DEC RAINBOW 100 mi n i -computer which was connected by an RS232 
interface to a VAX mi ni -computer . This software enabled the 
RAINBOW to emulate a remote terminal to the VAX. While in 
emulation mode, fil'? transfer could be performed between the 
VAX/VMS operating system and the? CP/M DOB operating system. Only 
ASCII data -Files could be transfered. Transfer of binary data 
would be possible if a POLY-XFR package was installed in the VAX. 
As part of the installation proress, various POLY-COM scr-ens 
were used to establish the communication parameters. 

POLY-COM was invoked on the RAINBOW using the "TRM" command. 
Through the resulting selection screen, the RAINBOW was placed in 
emulation mode. After signing onto the host from the RAINBOW, the 
"EDIT/EDT filename" command was used to lnvo^e the editor. The 
specified file name would be the destination of the file 
transfer. The editor was then placed in insert mode. The 
••SENDFILE" function of POLY-COM was then invoked by pressing the 
"SELECT" key followed by the "S" l-ev. A screen prompt would 
request for the file name of the file to be sent. Entering the 
■file name would initiate the actual data tran*i>fer. Thus to 
transfer the student or course file, the (iis^ette containing that 
file would be inserted in a RAINBOW di<iA drive, and the f\ie name 
would reference th^t file. Once initiated, data transfer 
continued until end of file was detected. The editor then 
returned to edit mode. An "EXIT" command caused an exit from the 
editor and saved the transferred data. If another file transfer 
was needed, this procedure was repealed beginning with invoiing 
the editor. To return to the RAINBOW iJClS environment, one should 
log off from the host and then press the "SELECT" ^ ey followed by 
the "X" l-ey. 

The maiJimum record length which coult? be properly transfnred 
using the POLY-COM utility was 254 L^haracters. If longer records 
wer-e used, an end of record would bfr assumed after the 2^!:ith 
character. Thus if record length of 25t: (maximum for a IBM/PC DOS 
file) was used, a record of zero length would be followed every 
rsctual record transfered. 



7.0 VAX- 11 DATA CGNVERSJGK 



The data transfer ed to tiht* VAX wpre in the ^orm uf sequential 
files. Ihese files must: be con v'f-?i' t ecJ to indere?cj ?-.equential files 
which formed parts of the SAS data bas->fi. The Record Management 
Services (RMS) ut3l]-t3G??s simplifjed this conversion 

si gni f 1 cant 1 y . 

RMS .itilities used v^^ere 'EDIT/fDL" arud "CONVERT". Each file in 
the system may be described b/ a collection of file-? attributes. 
File attributes were specified using the File Definition Language 
;'='DL). The set of FDL statement e-. which (ie^cribed the attributes 
of a file could be placed in i t^3 FDL file. An FDL file could be 
created using the editor and entering the FDL statements. A much 
simpler alternative was to use the EDIT/FDL utility. This 
facility guided the user in creating a F- DL file? through a series 
of menus, prompts and a help facility. POL <iles, LbSSIUD.FDL and 
CSSRFDU.FDL, were created for BAS student file, CBSSTUD, and 
course request rile, CSSREDU, r ei-.pect i vel y (see " oendi:: A. 2. 4). 

The ••CONVERT" utility was used to create a LSbS1 UD file according 
to its FDL specification and to load the download student 
demographic data into CSSSIUD. Each record in the download file 
was inserted into CSSSTIJD based on the specified ind'e:; fey. The 
content of tne record was not changed e;;cept that spaces were 
appended to adjust the record length to ZZO characters. "COh^VERT" 
disallowed any other data manipulation within a record. The 
course request data were similarly loaded using "LONVERT" e:icept 
that record padding was unnecessary. 
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The procedure nf-,ed to estahli<:^lT the si udent and course request 
data bases was successful. Heyond coping with the? limited record 
length that was encountered during dawnloadirig from the SEK'IE3/1, 
during data manipulation in the IBM/PC and duriny data tranc-.-fer 
frum the RAINBOW and the VAX, technical problem?, encountered were 
e;:pected and attributable to lac^ o-f e;;perience with the 
machines. A maj , nuisance was the c^moun k o-f ma M.ia] intervention 
in downloading from the SERIES/1. In general, the procedure was 
rather long-winded. Hence, this method o-f data trans-fer from the 
mainframe to the VAX would not be practical for frequent 
applications. For such appl i c^-^t i ons, simpler (more direct) 
methods of data transfer from mainframe to VAX siould be 
1 nvesti gated. 
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^^PPENDIX A. 1 



QyE?;ALL COMMUNICATION FLOW DIAGRAM 



IBM ^>341 
VM/ CMS 



VSERJE 

(BSC inter i ace) 



IBM 

SERIES/1 



IBM 3101 EMULATION PROGRAM 
(RS232 interface) 



IBM PC 
I OS 



dx B^ ette 
■i i le 



DEC 

RAINBOW 100 



POLY-COM 

(RSi:32 interface) 



VAX jl/71Tj 
VAX /VMS 



RMS 

UTILITY 



Data Base 
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APPENDIX A.2.i IBM 4341 DATA 



Record •format of student -file created -from data do.-jnloaded -from 
the mainframe to the SERIES/ Is 



r fFi n uYir:- rvrr fHAi.,;? 
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APPENDIX A. 2. 2 b&Bii/^^^l Ut)lt^ 



Reacord forrnats o-f student and cc)\u"^c^ reque^il ^ i I 
BERIEG/1 and downloaded to an IBM/PC: 



c reated i n the 



Lour<5e Request Rgl ord 



Field 


Ln 


Val ne 


REOU.SSrUDENflD 


9 




REQU.SCHLYEAR 


4 


1 VB4 


REOU.CRSEID 


6 




REUU. REQPRIQ 


1 


H 


F I LLbR 


14 




REDU.FILLSTATUS 


1 


1 


REOU.SEX 


1 




FTLLEf-' 


44 





Field 



Ln 



Studont f-.'ecord 1 



Val Lie? 



ESrUD. STUDENT ID 


7 




STUD, L.ABNAME 


18 




BTUD.BIVNAME 


14 




STUD.CALNAME 


8 




S1UD.ADDRLIN1 


25 




FILLER 


6 








Student Kecurcl 


Fi eld 


Ln 


Val ut? 


SrUU. 5 rUDENTID 


9 




STUD. ADDRLIN2 


25 




STUD. CITY 


18 


EDMON 1 UN 


STUD. PROVINCE 


4 


ALT A 


STUD. POSTCODE 


9 




STUD. AREACODE 







STUD. PHONE 
F ILLER 
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'efit Record 



Fig' ' Ln >a]u 

STUD. yiUDENTID 9 

FILLER 2'Jj 

SrUD.SEX 1 

STUD.BI -<THDATE 8 

FILLER' 34 

STUD. STATUS 1 A 

FILLER 2 



Btuucnt Record '1 



Field 



STUD.SrUDENTID 
STUD. GRADE 
SiTUD. eCHLYEAR 
FILLER 

STUD. ADMDATE 
STUD. ADMCODF 
FILLER 



Ln ValuH 



9 

4 B4 
24 

8 19fJ4(. 9ul 

1 D 
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APPENDIX A. 2. 3 IBM/PC DATA 



Record 
IBM/FC: 



■formats of student and course request files ._reated in thu 



Course Request Record 



Field 



Ln 



Val ue 



REQU. STUDENT ID 9 

REOU.SCHLYEAR 4 

REOU.CRSEID 6 

REQU.REQPRIC 1 

FILLER J 4 

REOU.FILLSTATUS 1 



1VB4 
M 
I 



I't' dent Kt?CDrd 



Field 



Ln 



Val ue 



STUD.STUDENTID 
STUD.LASNAME 
STUD.GIVNAME 
STUD.CALNAME 
STUD. ADURL INI 
SrUD. ADDRL1N2 
STUD. CITY 
STUD. PROVINCE 
SrUD. POSTCODE 
STUD. AREACDDE 
STUU. PHONE 
FILLER 
STUD. SEX 
STUD. BJr.THDATE 
FILL P 
STUD. STATUS 
STUD. GRADE 
STUD.SCHi YEAR 
FILLER 

STUD. ADMDATE 
STUD. ADMCODE 
FILLER 



9 

u 



J 3 



1 

8 
.'4 
1 

4 

24 
8 
1 
6 



EDMONl UN 
ALTA 



A 
0 
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APPENDIX A. 2 . 4 SAS DATA 
Record formats of student and course requests files in SAS 



(REQU) 

REQU.STUDENTID=9% 

REQU.SCHLYEAR=4% 

REQU.CRSEJD=»&% 

REQU.REQPRI0=1% 

REQU.ALTCRSEID=6% 

REQU.ASGNCRSEID=6% 

REQU.ASGNSECN0=2% 

REQU.FILLSTATUS=1% 



IMAP FOR CSSREQU 

! STUDENT ID: 

! SCHOOL YEAR: 

KCOURSE ID> 

!<PRIORITY> 

! <ALTERNATE> 

!<AS SIGNED COURSE> 

KASSIGNF^ SECTION> 

KFILLING 3TATUS> 
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100 REH Prograi ID ; STUDFN.BAS 

no REH 

120 REH Prograi ; File Extraction 

130 REfl 

140 REH Purpose : This prograi pitrarts student data 

150 REK doNnloaded froc an IBN SERlES/l 

160 REI1 to an l&r PC. 

170 REfl 

IBO REfl Input : ^il? II - downloaded student data 

190 REI* 

200 REft Output : File 12 - student data 

710 REH 

220 REH Processing. 

230 REH 

240 REH Once initiated, this prograi requires the 

250 REH user to enter the input and output file 

260 REh naies. H the output file already exist, 

270 REH its content mil be over written. This 

280 REH prograi exaaines input records. Records 

290 REH Nhich do not begin Mith a nuieric character 

300 REH are ignored. Other records are written to 

310 REH output file unchanged. 

320 REH 

330 REH 

1000 INPUT "ENTER INPUT FILE : ",INFILE$ 

1010 OPEN INFILE$ FOR INPUT AS II 

1020 INPUT "ENTER OUTPUT FILE : ",OUTFlLEi 

1030 OPEN OUTFILEI FOR OUTPUT AS 12 

mo INCTR = 0 

1050 OUTCTR = 0 

1060 HHILE NOT EOFU) 

1070 LINE INPUT ll,RECORDI 

1080 INCTR = INCTR f i 

1090 DTI = LEFT$(REC0RD$,11 

1100 IF DTI < '0' OR DTI > "9" THEN GOTO 1130 

1110 PRINT I2,REC0RDI 

1120 OUICTR = OUTCTR ♦ 1 

1130 NEND 

1140 CLOSE 11,12 

1150 PRINT • RECORDS READ : ";INCTR 

1160 PRINT "RECORDS WRITTEN ; 'jOUTCTR 

1170 END 
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100 REH Proorai IC ; STUDPTCH.BAS 
110 REH 

120 REM Prograi : Student Record Create 
130 REH 

140 REH Purpose : This prograi joins segients of 
150 REH student data to create student 

REN records suitable for loading into 

170 REH the SIERRA systei. 

180 REH 

190 REh Input : File 11 - first part of student data 
200 REH File 12 - second part of student data 

210 RtH File i3 - third part of student data 

220 REH File 14 - fourth part of student data 

230 REH 

240 RtH Output : File 15 - coiplete student record 
250 REH 

260 REH Processing. 
2/0 REH 

280 REH This prograi Ueratively reads a record 
290 PEH froi each input file. The four records 
300 REH read should belong to one student. This 
310 REH is identified by the student identification 
320 REH nuibers in the four records. If these 
330 REM nuibers are inconsistent, the prograi 
340 REH absorts with appropriate lessages displayed. 
350 REH Data in student recirds are joinned to 
360 REH fori a student record suitable for loading 
370 REH to the SIERRA school systei. Brades Hhich 
360 REH are less than grade 10 are adjusted to be 
390 REH grade 9. 
400 REH 
410 HtH 

1(00 OPEM "P, II, "STUDl.DAT' 

1010 OPEN M", 12, •STUD2.DAT" 

1020 OPEN M", 13, "SlUDS.DAT* 

1030 OPEN M', 14, •STUD4.DAT' 

1040 OPEN "0-, 15, -STUD. DAT- 

1050 COUNT = 0 

1060 NHILE NOT EOF(l) 

1070 LINE INP'JT II, STUD1$ 

1080 LINE INPUT 12, SilID?! 

1090 LINE INPUT 13, STUD3$ 

1100 LINE INPUT 14, SIUD4I 

1110 101$ = LEFTiiSTUDl$,9) 

1120 102$ = LEFT$(STUD2$,9) 

1130 ID3$ = LEFT$(STUD3$,9) 

1140 104$ = LEFT$(STU04$,9) 

1150 IF 1D1$ <> 1D2) THEN SOTO 1360 

1160 IF 101$ <> 1235 THEN GOTO 1380 

1170 IF ID1$ <> ID4$ THEN GOTO 1400 
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1180 SE6i$ = LEFT$(STUD1$,74I 

1190 SE6I$ = LEFT$(STUD2$,75) 

1200 SE62$ = RI6HT$(SE6](t,&6) 

1210 SEfi2i$ = LEFT$(SE62$,50I 

1220 SE6I$ ' RI6HT$(SE62$,iS) 

1230 SE622$ = LEFT$!SE6I$,3) 

1240 SE623$ = RI6HT$(SE6I$,12) 

1250 SE6X$ ' LEFT$(STUD3$,7B) 

1260 SE63) ' RI6HT$(SE6Xt,<>9) 

1270 SEBH = LEFT$(STUD4$,54I 

1280 SE6I$ ' RI6HT$(SE6]($,4S) 

1290 GRADE) = LEF7$!SE6»,2) 

1300 SE64$ ' RI6HT$(SE6]($,43) 

1310 IF 6RADE$ < MO' THEN GRADE) = '09' 

1320 PRINT I5,USIN6 •l=;SE61$4SE621$tSE622$f •♦SE623»*SE63<*ERADEv ^E64$ 
1330 CDUNT : COUNT * 1 

1340 NENO 

1350 60T0 1410 

1360 PRINT "STUDEND ID HISNATfH IN FILE STUD2.CAT : ABORTED" 

1370 60T0 1410 

1380 PRINT "STUDENT ID HISNATCH IN FILE STU03.DAT : ABORTED" 

1390 GOTO 1410 

1400 PRINT "STUDENT ID HISNATCH IN FILE STUDf.DAT : ABORTED" 

1410 PRINT "RECORDS WRITTEN :";COUNT 

1420 CLOSE 11,12,13,14,15 

1430 END 
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100 REM Prograi ID : STUDCOPY.BAS 

110 REH 

120 REM Prograi : File Copy 

130 REM 

MO REM Purpose ; This prograi extracts student data 

150 REM to a nuiber of sialler files. 

160 REM 

170 REM Input ; File II - source file 

180 REN 

190 REM Output : File 12 - outpi-t file 

200 REM 

210 REM Processing. 

220 REM 

230 REM Once initiated, this prograi requires the 

240 REM user to enter the source file raie, he 

250 REM taxiiui nuiber of record* to copy to an 

260 REM output file and the file naie of the first 

270 REM output file Records »re copied to the 

260 REM output fi e until eof or the aaxiiui nuiber 

290 REM of recofis has been copied to the output 

300 REM file. If eof has not been reached, the user 

310 REM IS reC'ired to enter the file naie of the 

320 REM next iutput file. This process continues 

330 REM intil eof is reached. 

340 RE 
J50 EM 

100 ^ INPUT "ENTER INPUT FILE : •,INFILE$ 

1010 OPEN INFILE$ FOR INPUT AS II 

1020 INPUT "ENTER HAIIMUH NUMBER OF RECORD / OUTPUT FILE : %MAX 

1030 INPUT "ENTER FPST OUTPUT FILE : "jOUTFlLEl 

1040 OPEN OUTFILEI FOR OUTPUT AS 12 

1050 CTR - 0 

1060 INCTR = 0 

1070 OUTCTR = 0 

1080 WHILE NOT EOF(l) 

1090 INPUT II, RECORDS 

1100 INCTR = INCTR ♦ I 

1110 CTR = CTR M 

1120 IF CfR > m T '.N 60SUB 1200 

1130 PRINT 12 EC0RO$ 

1140 OU^ TR = OUTCTR ♦ I 

1150 W 9 

1160 ^iOSE 11,12 

1170 PRINT • RECORDS READ : ViNTTR 

1180 PRINT 'RECORDS NRI'TEN ; "lOUTCTR 

1190 END 

1200 CLOSE i: 

1210 INFJT "OUTPUT FILE FULL - ENTER NEXT OUTPUT FILE NAME : ',0UTF1LE$ 

1220 OPEN OUIFILE$ FGP OUTPUT AS 12 

1230 CTR = 1 

1240 RETURN 

236 
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100 REfl Pro:rai ID : STUDREQU.BAE 

no RLI 

120 REH Prcgrad : Student Request Conversion 

130 REM 

140 REH Purpose : This prograi BOdifies student cou''se 

150 REH requests according to various criteria. 

160 REH 

170 REH Input : File 11 - source file 

IBO REH 

190 REH Output : File 12 - output file 

200 REH 

210 REH Processing. 

220 REH 

230 REH This prograi exaiines each course requ A 

240 REH and if required, perforis one of the 

250 REH folloHing conversions. 

260 REH 1. For feiale stu:;it, course "14450" is 

270 REH changed to '14451% "24450' to '24451' 

28u REH a-: "34450" to "34451". 

290 REH :. For student requesting course "1425B', 
REH an additional request is recreatt^d for 

:iO REH course "1426B\ Siiilarly, "1425W" is 

320 REH created for "1425N", "2426B- for '2425b", 

330 REH "242611" for "242511", '3426B" for "3-_5B" 

340 REH and "3426N" for "3425B". 

350 REH 3. A course ending with .i luieric digit 

360 REH less than 9 has that oigit replaced by 0. 

370 REH 

330 REH 

1000 INPUT "ENTER INPUT FILE ^^E : ",INFILE$ 

1010 OPEN INFILE$ FOR IN^l' AS II 

1020 INPUT "ENTER i-'TPUT FILE NAHE : ",OUTFILE$ 

1030 OPF^ lUTFILEi FOR OUTPUT A3 12 

1040 :tr = 0 

1050 . "TCTR = 0 

106' "^HILE NOT EOFil) 

1070 LINE INPUT II, RECORD* 

1080 INCTR = INCTR ♦ 1 

1090 FLD$ = LEFT$iREC0RDr:6) 

1100 PART!$ = LEFT<:-LD$,13) 

1110 PARTU * RIfHI$<FLD$,23) 

1120 COURSE! - LEFT$(PART)($,5) 

1130 PP''^2$ = RI6PTMFLD$,18) 

1140 iF COURSE! = "14450' THEN 60SUB 1320: GOTO 1270 

1150 IF COURSE! "24450" THEN 60SUB 1360: GOTO 1270 

1160 IF CObRSEi = "34450" THEN 60SUB 1400: SOTO 1270 

1170 IF COURSE! = '1425B" THEN 60SUB 1440: GCTO 127U 
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1180 IF COURSES = •1425W' THEN BDSUB 1480: GOTO 5270 
1190 IF COURSES = ':425B' THEN GOSL'B 1520: GOTO 1270 
1200 IF COURSES = •2425i<" THEN GOSUB 156U: SOTO 127" 
1210 IF COURSES = •3425B' THEN GHSUB 1600: GOTO i:7'' 
1220 IF COURSES = •3425H- THEN GOSUB IMO: GOTO 1270 
1230 LAST^ ^ RIGHTSICOURSES,!) 
1240 F'RSTS = LEFTS^C0URSES,4) 

1250 LASTS > "0" AND LASTS < THEN COURSES = FIRSTS ♦ "O* 

1260 GOSUB 1680 

1270 WENO 

!290 CLOSE 11,12 

1290 PRINT • RErORDS READ : "jlNCTR 
1300 PRINT "RECORDS I^-^ITTEN : ';OUfCTR 
1310 END 

1320 SEn = RIGHTSIPART2S,1) 

1330 IF E^XS = "F" THEN COURSES = M4451' 

1340 61SUB 1680 

13f0 RETURN 

1*60 SEXS = RIGHTS(PART2S.l) 

1370 IF SEX^ = 'F' THEN COURSES = ■24451' 

1380 GOSUB 1680 

1390 RETURN 

1400 SEU = RI6HTS!PART2i,l) 

1410 IF SEXS = 'F- THEN COURSES = •34451' 

1420 GOSUB 1680 

1430 RETURN 

1440 GOSUB 1680 

1450 COURSES = M426B" 

1460 GOSUB 1680 

1470 RETURN 

1480 GOSUB 1680 

1490 COURSES = '1426«" 

1500 GOSUB 1680 

1510 RETURN 

1520 GOSUB 1680 

1530 COURSES = ■2426B' 

1540 GOSUB 1680 

1550 RETURN 

1560 GOSUB 1680 

1570 COURSES = ■241611" 

1580 GOSUB 1680 

1590 RETURN 

1600 GOSUB 1680 

1610 COURSES = '3426B" 

1620 GOSUB 1680 

1630 RETURN 

IM GOSUB 1680 

1650 COURSES = •34.^«' 

1660 GOSUB 16t ' 

1670 RETURN 

1680 PRIK I2,PART1S*C0URSES*PART2S 

•690 OUTCTR = OUTCTR ♦ 1 OOo 
1700 RETURN ' OO 
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APPENDIX P. 4 VAX RMS UlILITY FOR DAJA CONVERSigN 



IDENT lO-PEC-1984 13:24:00 
SYSTEM 



FILE 



KKCOkli 



GOURCE 



ORGAN IZAT ION 



CARRIAGE CONTROL 

FORMAT 

SIZE 



VAX-ll FDL Editor 



1 ndpjie-l 



c r i "^^p. r c- tur f» 
3C) 



AREA 0 



AREA 1 



AREA 2 



ALLOCATION 
PEST^TRY^CONTIGUOUS 
t«'JCkET_SlZE 
EXTENSION 



ALLOCAT ION 
PEST^TRY CONTIGUOUS 
POCKET. SIZE 
EXTENSION 



ALLOCATION 
HEST^TRv CONTIGUOUS 
PUCKET^SIZE 
EXTENS ION 



:^4oo 

?.A0 



no 

Vf s 

e 



V *.» tb 



AREA 3 



KEY 0 



KKY 1 



ALLOCATION ?0 

l«EST^TRY_ CONTIGUOUS yf.s> 

BUCKET_s"lZE R 

EXTENSION 2 



CHANGES r»o 

IiATA^AREA 0 

riATA^FILL PC 

DUPLICATES no 

INPEX^AREA ] 

INDEX FiuL no 

LEVELl, INDEX AREA I 

PROLOGUE :> 

SEGO^LENGTH 19 

SEGO^POSIT ION 0 

TYPE «;lrir,M 



CHANGES vvs 

HATA AREA 2 

DATA^F ILL Bn 

PUPL ICATES VPS 

INDEX AREA :\ 

INDEX 'FI» I no 

LEVEL1_1NDEX AREA J 

SCGO LENGTH 6 

SEGO^POSITION J,^ 

TYPE -Annn 



TITLE cssitud fdl creiied at l.>-04-19b)4 



IPENT 7-PEC-1984 10:13:S7 
SYSTEM 



FILE 



RECORD 



AREA 0 



AREA 1 



AREA 2 



AREA 3 



KFY 0 



KEY 1 



SOURCE 



ORGANIZATION 



CARRIAGE CONTROL 

FORMAT 

SIZE 



ALLOCATION 

PEST TRY CONTIGUOUS 

PUCKET^sizE 

EXTENSION 



ALLOCAT ION 
FEST.TRY CONTIGUOUS 
BUCKET, SIZE 
EXTENSION 



ALLOCAT ION 

PEST TRY CONTIGUOUS 

PUCKET.SIZE 

EXTENSION 



ALLOCATION 
FEST TRY CONTIGUOUS 
fUCKET^S IZE 
EXTENS ION 



CHANGES 

data area 
data'fill 
duplicates 

INfiEX AREA 

inpexIfill 
level!, inpex^area 

NAME 

F'ROLOGUE 
HEGO. LENGTH 
SEGO POSITION 
TYPE 



CHANGES 

PATA AREA 

l'ATA_riI.L 

PIJPLICATES 

INPEX^AREA 

INPEX^FILL 

LEVELl^lNPEX AREA 

NAME 

SrOO. LENGTH 



VAX-1 1 rPL EdiLoi 



VAX/VMii 



1 nde*:e»J 



c*rriaqc return 
330 



30DO 
ye 5 
10 

3or. 



yvs 
10 



300 
yes. 

30 



11* 



rii» 
0 

80 
rifi 
3 

BO 
1 

5 t'J'j , S 1 Ud'M.l 1 .J 

3 

0 

s t r i ri 4 



'1 

00 
yr«, 

:i 

80 

:i 

stud. 1 1 5 »rl m 
IP 



fiEGO_POSITlON 9 
TYPE *,trir.M 
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APPENDIX 6: RECENT SYSTEM DEVELOPMENTS 



Hands on testing work for this project %7aB completed In spring, 1985. Since 
then, there have been some product announcements that may Infl nee 
mlnlcoDputer users* 

A» VAX Computer Announcements 

On May 16thy 1985, Digital Equipment announced the Micro Vax lln This Is a 
powerful 32 user computer with 70 to 210 Megabytes of disk storage » 90 Mbytes 
tape cartridge backup and a processor speed of 1 million Instructions per 
second making It nearly three times as fast, for CPU-bound activities, as the 
VAX 11/725 used for the trials. The starting price Is given as 25 thousand 
dollars. The MlcroVAX II also supports 5 1/4 Inch diskettes and up to 9 
Megabytes of memory. 

At the same time, Digital announced the Interconnection software and hardware 
for IBM PC/AT computers to be attached as Intelligent terminals. PCDOS files 
can be transferred to the host VAX computer and VAX/VMS files can be sent out 
to the IBM PC/AT computers. 

B. VAX-based Software 

Since completing the report, Edmonton Public Schools has received some 
Information about the Systems Eleven school Information management system. 
This product, which appears to have the backing of Digital Equipment Is being 
evaluated by the Calgary Board of Education and many school districts In 
Ontario* 

The Systems Eleven package provides the following functions: 

Student registration and scheduling, grade reporting, transcripts, dally and 
class attendance, accounting and child tracking. In addition. It provides a 
companion financial services package that has personnel am' payroll software, 
fixed assets. Inventory and census and taxes accounting. 

Whilst the package would appear to be a centralized solution, the addition of 
Intelligent terminals such as IBM PC computers would allow a measure of 
distributed data management. 

C. IBM Series 1 Computer Announcements 

IBM has announced a Series 1 co-processor board for the PC/AT microcomputer. 
The board provides full support for the Series 1 Instruction set and EDX 
Operating System. Mld-Amerlcan have stated that the PROMPT/PASS packages will 
run on the IBM PC/AT using this board. 

D. Series 1 Based Software 

Mid-American will be releasing an updated version of the Prompt datAha^e 
management system wl^h a fully Integrated high level language Interface to EDL 
(Operating System Command Language). There will also be B-Tree (balanced 
tree) data base algorithms and access to an unlimited number of files. 
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